• ? gid - 22.12.2017 13:42
  [допустим в режиме 20 мне нужно записать блок в адреса 137770 по 140060]
  Значит вы плохо продумали работу с доп.ОЗУ СМК и сами себе злой буратино, мучайтесь теперь.
  Небольшое количество грамотных людей разрабатывают ПО с учётом аппаратных возможностей и особенностей железа. Остальные старательно пытаются натянуть сову на глобус.
  ¤
  [или страница закольцована?]
  С какой стати? обычное линейное ОЗУ, только разбито на страницы, которые разбиты на сегменты, чтобы на БК, с не очень удобной организацией памяти, можно было хоть как-то к ним доступ иметь.
• ? gid - 22.12.2017 12:44
  А слабо заглянуть в табличку на http://forum.pk-fpga.ru/viewtopic.php?f=4&t=5369 ?
  Учтите, что адреса кристалла тоже инвертированы.
• ? gid - 22.12.2017 12:42
  Использовать можно все режимы, просто некоторые из них неэффективны, некоторые неудобны в плане использования.
  Порядок сегментов имеет значение лишь тогда, когда нужен упорядоченный доступ к очень большому объёму данных.
• ? gid - 22.12.2017 11:41
  Схемы без ошибок в то время - большая редкость. В этой схеме мало того, что с окном ошиблись, она включается по адресам 140000-147776. Так ещё не учли, что регистры-защёлки адреса не инвертирующие. Видимо скопипастили с обычных для того времени схем с инвертирующими регистрами. Если посмотреть почти абсолютно такую же схему в ПК БК №1-1993, статья начинается со стр.72,
  то там уже дешифрация правильная. Регистры-защёлки адреса те же самые, ловится комбинация бит 15-13 - 001, и правильно написано, что работает в адресах 140000-157777
• ? gid - 22.12.2017 10:06
  [Подскажите правильно ли я понял:]
  Правильно. Но если нет дисковода, последняя команда (mov #0,@#177130) необязательна, она просто выключает мотор и светодиод дисковода, которые могут включаться при переключении страниц.
  ¤
  [и еще можно ли в качестве эксперимента загрузить туда РОМ Басика из эмулятора gid (bk11_198_basic1.rom,..2, ...3)]
  Нельзя. ПЗУ бейсика не может работать из ОЗУ СМК, т.к. рассчитано на организацию памяти БК, а не СМК. Вам об этом уже сказали.
  ¤
  [БК11М с СМК можно попробовать 10чный бейсик грузить, с монитором, естественно (который со 100000).]
  Это возможно только в режиме 20, при этом надо отключить регистры дисковода по чтению, потому что третья ПЗУ бейсика занимает адреса 160000-177600.
  В результате получим БК10, которой требуется магнитофон для работы, т.к. ПЗУ бейсика БК10 работает только с ним. А любая ОС, перехватывающая EMT36 при этом будет недоступна, т.к. бейсик займёт всё адресное пространство.
  ¤
  [правильно ли я делаю и про образы ПЗУ которые]
  Про образы ПЗУ неправильно и бессмысленно. Всякое ПО надо использовать так и там, для чего оно предназначено. Либо писать своё.
• ? gid - 21.12.2017 16:51
  [На диаграмме уж очень все смещено и непонятно]
  Если там непонятно, посмотрите вот туда http://www.emuverse.ru/downloads/datasheets/processors/k1801/k1801-844012-18.djvu
  Это вырезка статьи про 1801ВМ1 из журнала МПСС №4-1984.
  Там диаграмма чтения дана на рис.3 и описана более популярными терминами.
  Вообще, про проц 1801ВМ1 с такими диаграммами писалось ещё где-то, в каком-то справочнике, но я не помню где. И с ходу не нашёл, а ГОСТ 26765.51-86 под рукой всегда.
  ¤
  [сформируется вот такая картина: 110000000000000]
  это 140000. А 120000 - это 1010000000000000. Но этим данным будет предшествовать установка сигнала BSY... в общем и далее по диаграмме.
  ¤
  [при включении бк она обратится к этой ПЗУ по этому адресу и выполнить эту команду]
  Нет. Адрес запуска БК10 - 100000, БК11 - 140000. Чтобы поменять адрес запуска на свой без модификации БК, можно посмотреть, как это сделано в контроллерах СМК (подсказка - наложение ПЗУ на область регистров в момент запуска, чтобы получить свой адрес запуска в регистре 177716)
  ¤
  >>? dima83 - 21.12.2017 16:05
  [так?]
  >>? dima83 - 21.12.2017 16:07
  Очевидно же, что да. Между прочим, так работают абсолютно все компьютеры. И до сих пор. И даже божественный IBM PC. Даже любой современный компьютер при запуске начинает выполнение программ из ПЗУ, как бы они не назывались (ROM BIOS, UEFI и т.п.)
• ? gid - 21.12.2017 15:33
  [стоп-стоп! Почему шина инверсная???]
  потому что. Это такой же факт, как вода - мокрая, а масло - масляное. Убедиться в этом можно, воспользовавшись логическим анализатором. Адрес 120000 на шине он покажет как 057777
  ¤
  [120000, мы попадаем в нулевую ячейку ПЗУ, к 120001 - к в первую и т.д.]
  У ПЗУ (конкретно у 1801РЕ и 1801РР) 16 разрядная архитектура. Они не умеют выдавать байты. На байты, которые нужны, получаемое слово делит процессор.
  Причём это всех устройств касается, не только ПЗУ. Просто примите как данность, что на шине МПИ обмен идёт всегда словный, даже если нужен байт, выдаётся всегда слово, и устройство само должно решать, какой байт из слова ему нужен, и как им распорядиться.
• ? gid - 21.12.2017 13:54
  [Примечательно, что разряд А12 так же участвует в дешифрации]
  А вот в дешифрации адреса регистра 177716 в микросхеме 1801ВП1-037 участвуют разряды А15..А1.
  Очевидно же, что чем меньше используемых адресов устройства сидят на общей шине, тем больше разрядов нужно, чтобы опознать свой адрес.
• ? gid - 21.12.2017 13:45
  106, 108 и 107, 019 и 018 - это просто кодовые номера, по которым можно узнать, что записано в ПЗУ, просто взяв их в руки и посмотрев глазами.
  ¤
  [Так чему равен из внутренний адрес "А13-А15"?]
  смотреть там http://forum.pk-fpga.ru/viewtopic.php?f=4&t=5369 (столбец Chip Code)
  Не забываем, что на шине МПИ все сигналы инвертированы.
  ¤
  [но ведь ведь обращаться то нужно непосредственно к адресному пространству самой МС?!]
  нет. Обращаться надо к доступному адресному пространству 000000..177777, внутри которого и находятся все доступные ПЗУ.
  ¤
  [Иными словами произвойдет дешифрация адреса.]
  Ну и произойдёт. И что? Дешифрацию адреса делают все устройства, сидящие на ОШ и имеющие на ней ресурсы: порты, регистры, память и т.п. Это такой принцип работы. Микросхема ПЗУ - одно из таких устройств.
  Потому что шина одна на всех, активное устройство - в данном случае процессор выставляет адрес, и устройства должны сами узнать, какому из них этот адрес принадлежит, чтобы принять/выдать данные и сигнал RPLY.
• ? gid - 21.12.2017 11:54
  Ну я могу ответить. На шине будет точно такая же диаграмма, которая в ГОСТе обозначена как Черт.5 на стр.14. Только на АД вместо слова "Адрес" надо подразумевать число 120000, вместо слова данные - число 012701 (первое слово микросхемы ПЗУ Бейсика БК10 1801РЕ2-106). Словесное описание последовательности появления/снятия сигналов дано там же, в п.п. 4.2.1.х
  ¤
  Вообще, на первом этапе из ГОСТа достаточно усвоить всего три диаграммы: Чтение (Черт.5), Чтение-модификация-запись (Черт.6), Запись (Черт.7). И их словесное описание из п.п. 4.2.1.х.
  ¤
  Ничего другого на шине в БК больше не делается. Только последовательность этих вот трёх диаграмм в разных комбинациях, плюс диаграммы прерываний при их возникновении. Ну и однократно - стартовая последовательность (Черт.15) при включении питания.
  ¤
  Описывать их словами - долго, нудно и не интересно.
• ? gid - 20.12.2017 10:25
  [можно сделать универсальный загрузчик через @#160006 для себя любимого]
  Вот так вот все начинали с этого, и некоторые не бросили эту затею и доходили до конца. В результате имеем зоопарк разных ДОСов. Т.к. после того, как будет сделан загрузчик файлов с дискеты, во весь рост встанет проблема хранения этих файлов на дискете, т.е. файловой системы - выбрать готовую или изобретать свою.
  Если будете изобретать свою, - рекомендую делать что-то совместимое с fat12 или ext, ext2.
• ? gid - 18.12.2017 20:12
  Ну так написать свой перехватчик емт36 с той реализацией, какая нужна самому - это и есть самая, что ни на есть отвязка от всех досов.
• ? gid - 18.12.2017 16:50
  Фрагмент кода немного странный.
  После EMT 36 зачем нужен BEQ EX?
  Т.е. теоретически EMT не меняет признаки, и BEQ EX должен выполняться всегда. Но точно ли не меняет?
  А вообще, нужно проверять адрес 1(R1) и если там не 0, то файл не загрузился по разным причинам.
• ? gid - 18.12.2017 16:43
  на пост ? dima83 - 18.12.2017 15:16
  Пока вы внимательно не изучите, и не прочитаете ГОСТ 26765.51-86
  Пока не переведёте описанные там словами алгоритмы обмена данными на шине с ужасного формального языка на простой понятный разговорный язык. Как там всё работает, так и будет оставаться непонятной загадкой.
  ¤
  Хотя, можно поискать информацию по 1801ВМ1, начав с википедии, там где-то были ссылки на статьи из журнала "МПСС", где давалось популярное описание работы процессора, с более менее человеческим описанием циклов обмена данными по шине.
• ? gid - 18.12.2017 16:33
  [а каково состояние каждого пина этой шины в каждый момент времени.]
  Verilog модель процессора 1801ВМ1 погонять в мультисиме подойдёт? брать там http://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
• ? gid - 18.12.2017 12:40
  Не понимаю вашу терминологию. И не понял вопроса. Диаграммы обмена данными даны в ГОСТ 26765.51-86 там всё ясно и почти чётко нарисовано, что зачем, в каком порядке шевелится на линиях.
• ? gid - 18.12.2017 12:15
  [Чем она отличается от обычных программ?]
  Ничем. Это обычная программа, и она будет такой, какой вы её напишете.
  [Так?]
  Технически так, но практически пользы от этого нет. Она должна загружать в ОЗУ основную систему, в которой будет реализована работа с пик-контроллером, и которую так же придётся писать вам.
  ¤
  После включения БК, адрес запуска берётся из регистра 177716, мл. байт игнорируется.
  Для БК10 там 100000. БК стартует с этого адреса, там находится монитор БК. Монитор запускается, делаются разные инициализации, потом выполняется команда CALL @#120000. И если по этому адресу что-то есть, то оно и запускается.
• ? gid - 18.12.2017 10:20
  [Если я все правильно понял]
  неправильно. ПЗУ находятся в адресном пространстве, доступном CPU, и программа оттуда выполняется ровно так же, как и из ОЗУ, только из ПЗУ.
  ¤
  [загнать с помощью пика и двух сдвиговых регистров самую примитивную программу в машинном коде в БК]
  невозможно силами только самого пика. Со стороны БКшки кто-то должен принимать данные со сдвиговых регистров, т.е. должен быть драйвер-загрузчик, который обычно размещают в своём ПЗУ. Данные можно принимать по ТЛГ линии на порте УП (только иногда её(линию) надо допаять проводочками, иногда - просто нужную перемычку замкнуть, на очень старых БК - ничего не надо, там всё сделано на заводе). Можно на МПИ навесить свой регистр и с него принимать сразу байтами или словами данные. А можно и побитно, тут от фантазии и умения в схемотехнику зависит.
  ¤
  [Да еще так, что бы она запускалась автоматом при включении питания.]
  Можно сделать, чтобы драйвер-загрузчик запускался автоматически, а уже он запускал принятую прогу. По-другому никак.
  ¤
  [единственно что я пока не очень понимаю протокол обмена кб с внешним пзу]
  Протокол обмена по шине МПИ описан в ГОСТ 26765.51-86 "Интерфейс магистральный параллельный МПИ системы электронных модулей. Общие требования к совокупности правил обмена информацией", легко гуглится, но не легко понимается. Он един для всех устройств на на шине МПИ, будь то ПЗУ, ОЗУ, процессоров, контроллеров и всего, что угодно, работающего по протоколу интерфейса "Общая шина".
• ? gid - 17.12.2017 17:42
  [По логике получается, что если бы в МСТД была установлена всего лишь одна МС, то для дешифрации адреса хватило бы всего 12 разрядов?]
  нет, нужны все 15. Внутри микрух 1801РЕ, 1801РР есть встроенный селектор адреса, по которому микросхема и определяет, когда обращаются к ней, чтобы выдать на шину данные и сигнал RPLY.
  Селектор как раз смотрит три старших разряда адреса. Эти три разряда жёстко и однократно задаются при программировании микросхемы и называются её адресом. Перепрограммировать их потом уже нельзя (даже у 1801РР). Поэтому эти ПЗУ можно тупо вешать друг на друга бутербтродом, если у них разные адреса. Отключаются от шины подачей высокого уровня на ногу 23.
  А14 БЛК как раз тот сигнал, который отключает от шины микросхемы бейсика, чтобы их место заняли микросхемы фокала и тестов с теми же адресами.
  ¤
  А почему фокал запускается автоматически? Да просто потому, что так записано в программе монитора. При старте БК в мониторе после всяких инициализаций выполняется команда CALL @#120000, и если по этому адресу есть бейсик - запускается он, если есть фокал - запускается он, если ничего нету - остаётся работать монитор и ждёт команды пользователя.
• ? gid - 14.12.2017 15:10
  Блок МСТД - это просто ПЗУ, которое садится на шину МПИ вместо ПЗУ бейсика. Сравнение с каким-либо контроллером тут неуместно.
  А бейсик и фокал - это просто программы, которые выполняет процессор, потому что он должен же что-то выполнять во время работы компьютера. Вместо бейсика или фокала в том же ПЗУ может быть всё, что душа пожелает и хватит умения приспособить прогу для работы из ПЗУ.
• ? gid - 14.12.2017 09:35
  Да.
  Но, как правильно заметил ММ, дело может быть и не в микросхеме, а в линиях на печатной плате - КЗ, обрыв, утечки.
  Если сбойный бит не всегда сбоит одним и тем же образом, а "мигает" - то нужно сначала прозвонить дорожки. Не замыкают ли соседние адресные линии с собой или чем-нибудь рядом. В общем долгая и кропотливая реставрация.
• ? gid - 13.12.2017 10:01
  [если у меня эмулятор запущен в системе дос, то обратиться к образу, в который записывается файл я уже не могу. не удобно]
  Это сделано умышленно. потому что БКшный софт подразумевает монопольное использование дискеты. И что-то писать туда со стороны недопустимо. Просто оказалось, что в микрософтовском классе CFile нельзя запретить доступ по записи, оставив доступ по чтению, поэтому доступ блокируется полностью атрибутом CFile::shareDenyWrite, который как казалось бы должен блокировать только запись. Если что-то нужно прочитать/записать - отмонтируйте дискету, прочитайте/запишите, что нужно, и примонтируйте обратно.
  А если выключить эмуляцию ввода-вывода дисковода, чтобы включилась эмуляция вращения дискеты, то там будет вообще полная несовместимость с совместным доступом к ресурсам.
  ¤
  [Ни кому в голову не приходило написать нормальный отладчик в полноценном windows-окне с возможностью использования буфера обмена и т.д.]
  Нормальный блин отладчик ему. Тут нормальный эмулятор-то написать не получается. Кто хочет - не умеет, умеет только хотеть. Кто может - тому нафиг не нужно БК какое-то.
  Я делаю так:
  1. пишу прогу в обычном Notepad++ с удобствами и подсветкой синтаксиса.
  2. компилирую в кроссассемблере турбо.
  3. записываю полученный бинарник в рабочий образ
  4. монтирую образ в эмуляторе и смотрю как работает и отлаживаю места, которые работают не так, как я ожидал. Попутно правлю в нотепааде исходник.
  5. если необходимо, гото 1
  если нужно опробовать прогу на реальной БК, то записываю рабочий образ на дискету прогой ukdsk c драйвером fdrawcmd
  и использую дискету на реальной БК.
  ¤
  [скажите почему при зацикливании проги в турбо 8 и остановке ее клавишей стоп прога вылетает в монитор?]
  А куда ей вылетать? Перенаправьте вектор 4 туда, куда хотели бы.
  Если запускали прогу из-под самого турбо8 и получили вылет в монитор, то значит каким-то образом турбо 8 повредилось или был переинициализирован вектор 4.
  Если запускали прогу из-под оболочки какой-либо ОС и получили вылет в монитор, то значит каким-то образом оболочка повредилась.
• ? gid - 12.12.2017 10:37
  Это ММ знает, он как-то подсказывал человеку в этой теме http://zx-pk.ru/threads/25358-zamena-vykushennykh-kondensatorov.html
  см. 3-ю стр.
  ¤
  А я думал, думал, и ничего не придумал, кроме как смотреть биты в сбойном слове. бит 0 - DS1 ... бит 15 - DS16.
  Я даже пробовал вывести формулу зависимости адреса микрухи от номера окна и адреса в окне, с этими RAS и CAS, и всё равно пришёл к битам, по-любому же менять микросхему целиком, даже если в ней сбоит всего один бит в одном ряду. Что выражается в одном сбойном адресе, где нибудь в 3-м окне.
• ? gid - 06.12.2017 16:41
  что-то переводы строк сожрались, и метки timeout$: и buffer: с предыдущей строкой склеились.
• ? gid - 06.12.2017 16:37
  [И вообще тут кто нибудь может написать фрагмент проги постоянно опрашивающей порт, запускающей таймер по изменению логики на порту]
  Ну, вот частично пример проги.
  MOV #177714,R5 ;порт УП
  MOV #177712,R4 ;управление таймером
  MOV #177710,R3 ;счётчик таймера
  MOV #77777,#177706 ;начальное значение таймера
  CLR R0 ;аккумулятор
  MOV #buffer,R1 ;буфер, куда сохраняем данные
  3$: MOV #8.,R2 ;счётчик битов
  ;допустим подключили ИК датчик к биту 7, чтобы проще было
  2$: MOV #34,(R4) ;запускаем счётчик в режиме одновибратора
  1$: TSTB (R4) ;таймер досчитал до конца?
  BMI timeout$ ;да - никаких импульсов не пришло
  TSTB (R5) ;опрашиваем ИК датчик
  BMI 1$ ;пока не придёт 1 (у порта УП входы выходы инверсные)
  CMP (R3),#NNN ;сравниваем значение таймера с контрольным значением
  ROL R0 ; после сравнения бит С будет 1, если blos - т.е.
  ; значение таймера меньше равно контрольного, т.е.
  ; длинный импульс, т.е. единица. И 0, если bhi - т.е.
  ; значение таймера больше контрольного, т.е. короткий
  ; импульс, т.е. нуль.
  SOB R2,2$ ; и так все 8 битов байта
  MOVB R0,(R1)+ ;сохраняем байт в буфер
  BR 3$ ;и идём получать следующий байтtimeout$:
  ; отсутствие импульсов считаем концом передачи
  ; и делаем что хотим, например выводим на экран.
  mov R1,R2
  sub #buffer,R2 ;узнаем, сколько байтов прочитали
  Beq 4$ ;нисколько
  ;тут п/п вывода байта в 8чном или 10чном виде. лень набирать.
  4$: halt ;всё конец работы. что делать дальше сами придумайте.buffer: .BLKB 100
  .END
  [подсчитывающей разность таймера и выводящей эту разность на экран?]
  вот тут можно переделать код - там где сравнение с контрольным значением - запись его в буфер.
  когда буфер переполнится - остановиться и вывести содержимое буфера на экран, так можно будет подобрать контрольное значение.
• ? gid - 06.12.2017 14:07
  [согласно протоколу NEC]
  а как вы собираетесь измерять длительность интервала между импульсами, чтобы отличить 0 от 1?
  или это ИК приёмник делает, и передаёт уже байты посылками со старт/стоп битами и битом чётности?
• ? gid - 06.12.2017 13:54
  >>? a214
  Что за такая программа на Бейсике? Вообще не помню такого. Как хоть называется?
  ¤
  [тот же в wav формате и тут эмулятор завис наглухо]
  Использовать wav файлы в эмуляторе - плохая идея. В этом нет смысла, а wav проще сконвертировать в bin в том же менеджере лент. Работа с бинами быстрее в разы и удобнее (меньше действий надо делать).
  wav нужен только для того, чтобы загрузить файл на реальную БК через магнитофонный вход.
  ¤
  [а если его загрузить из под бейсика как оно будет работать?]
  никак не будет. Бейсик использует ОЗУ БК под свои нужды, и если запортачить ему его рабочую область посторонними данными, произойдёт всё что угодно, и в конце-концов зависание.
• ? gid - 06.12.2017 11:49
  Порог вхождения в программирование на БК гораздо выше, чем на ZX. Бейсик БК для хоть чего либо, требующего более-менее какого-то быстродействия, совершенно не годится. Писать напрямую в кодах программу, длиньше чем пара десятков байтов, - сложно и гораздо дольше, чем написать её же на ассемблере и скомпилировать. одни смещения переходов задолбаешься считать, а потом пересчитывать, если надо будет вставить код куда-нибудь в середину.
   
  Тоже сейчас взял бинарник Mirage, который грузится по адресу 66000, сконвертировал его в .wav в менеджере лент в эмуляторе.
  Загрузил для начала бинарник в эмуляторе, в конфигурации БК10.
  Затем выключил опцию "Эмулировать загрузку ленты" и загрузил Mirage в формате .wav. Звук пищалки должен быть включен, иначе .wav не грузится. Загрузилось. (подразумевается, что пользователь знаком с командами монитора и знает что, когда и почему надо набирать на клавиатуре)
• ? gid - 06.12.2017 09:48
  В руководстве по мониторной системе для БК-0010-01 даны так же и примеры, они в 4-м столбце таблицы.
  В руководствах по мониторной системе для БК-0011(М) примеров нет, т.к. система команд слизана с ДВК и все примеры остались в документации по ДВК, см там http://forum.maxiol.com/lofiversion/index.php/t5004.html книгу "ПО ДВК [TIFF] Книга 3 - Ассемблер Паскаль Бейсик", а в ней раздел "ОТЛАДЧИК И ВИРТУАЛЬНЫЙ ОТЛАДЧИК. РУКОВОДСТВО ОПЕРАТОРА"
  Если этих примеров недостаточно, следует отказаться от затеи прогать прямо в кодах.
  Если лень искать и читать множество разрозненной и зачастую не связанной с БК документации, следует отказаться от затеи вообще как-то связываться с БК.
• ? gid - 28.11.2017 13:17
  [А вот про то, что ОЗУ 11-й тормознее - не знал.]
  Оно не тормознее. Оно такое же. Просто процессор быстрее на 1МГц, и соответственно тормознутая скорость работы ОЗУ становится ещё заметнее.
  ¤
  [то почему скорость выполнения одинаковая]
  Вообще-то не одинаковая. Я немного неточно выразился. Разница в скорости на 3 и на 4МГц хоть и есть, и даже на глаз заметна, но для работы драйвера несущественна, вот в этом смысле одинаковая и вот поэтому СМК отлично работает и на 10-ке, и на 11. Он и на 6Мгц вполне работоспособен. А так, да, чем выше частота, тем меньше времени на выполнение команды и дальше мы просто упрёмся в быстродействие ПЗУ. Ведь перед выполнением команды, её сперва надо прочитать из ПЗУ. Сколько раз выполнить, столько раз и прочитать. Кеша команд у ВМ1 нету.
  ¤
  [Для чего? И почему именно 15]
  В посте от 28.11.2017 09:39 я сделал предположение для чего.
  ¤
  [почему у FDD не сделать проверку по битам?]
  потому что битов не хватит. Нужно вводить команды как у HDD. и в результате получится тот же HDD.
  [Дали команду перехода на дорожку - ждем бита готовности]
  В HDD именно так. много разных команд.
  [Но как быть с адресным маркером? Ведь команды его поиска нет.]
  Как в HDD - перебросить эти заботы на аппаратную часть.
  Хотите эмулировать - берите код эмулятора HDD и сделайте там аппаратные ограничения - только 2 стороны и только 80 цилиндров. И количество секторов как-то можно ограничить в разумных пределах. Вот и получится продвинутый флоп. Но с ВП1-128 он уже не будет иметь ничего общего.
• ? gid - 28.11.2017 09:39
  Хорошо. Признаю, был не прав.
  Задержки в драйвере с помощью магических констант не важны. Драйвер одинаково ровно будет работать хоть на 20МГц, хоть на 100МГц.
  и код:
  FINDH:  MOV  #15., R0
  1$:  TST  (R5)  ; Вхолостую прочитаем
    SOB  R0, 1$  ; 15. слов
  тоже не ошибка, а просто неверный комментарий. Тут не 15 слов читается, а просто эвристически подобранная задержка в мс, зависящая от быстродействия команды tst (r5) и магического числа 15., чтобы подгадать чтоб диск прокрутился от заданной точки до области адресного маркера.
  Потому что везде правильное чтение данных делается так:
  1$:  TSTB  (R4)  ; Ждем готовности
    BPL  1$
    MOV  (R5), R1 ;получаем данные
  Чтобы гарантировано прочитать новые данные, а не одно и то же подряд несколько раз.
• ? gid - 27.11.2017 13:02
  А мы про какие задержки говорим? ПЗУ, в котором драйвер, что на 10ке, что на 11ке одно и то же, и работает с одной и той же скоростью, чтение опкодов из ПЗУ происходит одинаково медленно, что на 3МГц, что на 4 МГц. Собственно чтение/запись дискеты делается синхронно, по биту готовности, так что и тут от частоты не зависим.
  Как мне кажется, разработчики драйвера приняли за аксиому, что частота процессора никогда не может быть выше 5МГц, ну 5.5 максимум, поэтому сделали в драйвере ряд упрощений.
  Я вижу там несколько моментов:
  1. позиционирование с дорожки на дорожку. Там задержка на реакцию дисковода задана константой. И если будет частота проца сильно большая, то команды перехода будут подаваться слишком быстро, и дисковод не будет успевать спозиционироваться куда нужно.
  2. INDEX: П/п проверки диска и числа оборотов. Там тоже счётчик циклов. При большой частоте может быть нарушена логика работы и драйвер будет считать, что диска нет или он не крутится.
  3. FINDH: П/п поиска адресного маркера - там вообще ошибка, делается чтение 15 слов данных без готовности данных, т.е. - простой цикл. И на малой частоте это работает, на большой - вряд ли будет.
  4. STREAD: П/п запуска чтения и т.п. управление дисководом - установка и сброс битов делается через задержку. На большой частоте дисковод перестанет успевать реагировать на команды должным образом.
  Всё это станет критично, если с повышением частоты проца будет соответственно увеличено и быстродействие памяти, в которой находится драйвер. Если по-прежнему использовать тормознутые ОЗУ/ПЗУ, то всё скорее всего продолжит работать даже при частоте проца 100МГц.
   
   
  Число тактов команды 11-й больше, чем у 10-ки потому, что ОЗУ тормознутое. Чем выше частота, тем больше тактов проца расходуется вхолостую в ожидании, когда же ОЗУ соизволит предоставить процу доступ к себе, чтобы проц что-нибудь прочитал/записал оттуда. Всё логично. на 6МГц на выполнение команды затрачивается ещё больше тактов. Причем не в 2 раза больше, чем на 3МГц как ожидалось, а ещё больше.
  При повышении частоты процессора, быстродействие повышается, но не настолько, как могло бы, если бы не ОЗУ.
• ? gid - 17.11.2017 12:00
  [Это с реальными таймингами команд ВМ1 или это независимо от таймингов?]
  Никаких реальных таймингов нет. Примерные тайминги: для БК10 - Зальцмана. для БК11 - то, что натестировалось на 4МГц.
  Это не только CPU, это ещё и всё, что выполняется в ExecuteFrame();
  Обработка звука - пищалка, ковокс, AY, захват звука с линии. (всё кроме захвата - отключается)
  В пищалке - эмуляция заряда/разряда конденсатора, чтобы звук пищалки был как у настоящей БКшки (не отключается, т.к. нужна привязка к реальному времени)
  + у всех звуковых устройств постоянно заполняются буферы фильтров БПФ, даже если фильтр выключен, чтобы при включении не было щелчков.
  Эмуляция хода луча ЭЛТ, и затухания люминофора (отключается).
  Эмуляция вращения дисковода (отключается).
  Вычислений - овердохрена, эмуляция инструкций - это мелочь. Поэтому и 20МГц, дальше - фрейм становится длиньше 40мс.
  ¤
  [Скорость вывода звука на самом деле скачет, потому что он выводится блоками]
  Это смотря как программировать. Хоть звук и выводится блоками, но пока не отзвучит один блок за строго определённое время и не появится хоть один свободный блок, следующий блок передать звуковухе нельзя, приходится ждать, и вот эти-то ожидания и дают чёткую синхронизацию с реальным временем. Скачок происходит в самом начале, когда буферы только заполняются, но этого никто не замечает. А звук у меня выводится всегда, когда ничего не звучит, на звуковуху отправляется тишина.
  ¤
  [Если ускорять, то только переписывать на чистый асм.]
  не поможет. Даже замедлит, компилятор оптимизирует лучше, чем например я пишу на асме. Мой код получается медленнее кода, сгенерированного оптимизирующим компилятором.
• ? gid - 16.11.2017 21:28
  Я подошёл к задаче с другой стороны, в общем так же как и в посте [ Дмитрий - 16.11.2017 18:58 ]. Время разделил на фреймы по 40мс. Константа. Я предположил, что число эмулируемых тактов ВМ1, укладывающееся во фрейм априори выполняется на современных компах быстрее, гораздо быстрее, чем 40мс, поэтому WaitableTimer у меня используется как замедлитель.
  1.Запускаешь таймер
  2.выполняешь вычисления фрейма
  3.ждёшь пока таймер не отсчитает свои 40мс, или не ждёшь, если вычисления фрейма затянулись и таймер уже своё отсчитал.
  4.идёшь к пункту 1.
  Кстати, если число выполненных тактов превысило число расчётных тактов, то ими я не пренебрегаю, а переношу в следующий фрейм. Т.е. если текущий фрейм оказался длиннее расчётного на 12 тактов, то следующий должен быть короче на 12 тактов, т.о. у меня постоянно сколько-то тактов переносится в следующий фрейм.
  ¤
  При этом экспериментально выяснилось, что максимальная эмулируемая частота ВМ1 может быть 20МГц. На большее просто не хватает вычислительных возможностей, Вычисления длятся больше, чем 40мс и не укладываются во фрейм.
  Нужно менять алгоритмы. Вводить многопоточность, чтобы потоки работали независимо, синхронизируясь между собой. При этом люди с двух и одноядерными процами окажутся в пролёте из-за сильно упавшей у них производительностью.
  А все мои эксперименты с многопоточностью приводили к тому, что многопоточная прога начинала работать заметно медленнее однопоточной из-за многократного переключения контекстов потоков для доступа к расшаренным данным, на которые тратилось 90% всего процессорного времени.
  В общем не осилил я пока нормальные высокопроизводительные вычисления.
• ? gid - 16.11.2017 15:39
  Когда ставишь -10000000LL (ровно одна секунда) появляются микроразрывы между воспроизведениями звуковых буферов. И звук получается грязный и попёрдывающий.
  ¤
  Это связано с тем, что на самом деле в эмуляторе синхронизация в реальном времени происходит через воспроизведение звука - единственное место в виндовсе, где можно как-то привязаться к реальному времени.
  А этот фрейм - привязка UI к реальному ходу времени (Тут в отличии от звука можно делать примерно, а не точно - инерционность зрения и психовосприятия окружающей обстановки - мозг сам подстроится и скорректирует картинку со звуком). Поэтому там задержка должна быть чуть меньше, чтобы всё шло гладко.
  На самом деле, здесь можно вообще убрать и задержку и таймеры. И всё будет работать как ни в чём не бывало. Но только до момента, когда в системе есть устройство воспроизведения звука. Как только убрать все звуковухи, всё начнёт скакать с максимально возможной скоростью, без задержек. Поэтому и стоят в этом цикле и задержки и таймеры.
  ¤
  Кстати, что мешает поэкспериментировать? задать интересующее значение и пересобрать эмулятор, многие вопросы могут отпасть сразу.
• ? gid - 16.11.2017 10:33
  [А что, кстати, было переписано в ней в 3.9?]
  Раньше было можно через условную компиляцию использовать два варианта - или QueryPerformanceCounter, или WaitableTimer.
  А сейчас, если аппаратное обеспечение поддерживает QueryPerformanceCounter, то используется он для задания задержек для WaitableTimerа, если не поддерживает - то для WaitableTimerа используется константная задержка, как было раньше.
  ¤
  [А что сложного?]
  Чуть не так. Там надо выводить диалог, для БК10 и БК11 разный, где можно изменить номера подключенных страниц сейчас (для БК10 неактивно), выбрать файл, взять адрес загрузки из бин заголовка, если он есть у файла или задать свой адрес загрузки, проверить размер файла, помещается ли он в ОЗУ БК с задаваемого адреса и если всё ОК - применить загрузку. Если файл не помещается - можно обрезать и всё равно применить загрузку.
  Сохранение файла - тоже свой диалог, с выбором страниц (для БК10 неактивно), выбором начального адрес, заданием длины или конечного адреса (на выбор, если задаётся длина - конечный адрес корректируется, если задаётся конечный адрес - корректируется длина, чтобы всегда можно было выбрать размер одним из двух способов), выбором имени файла и формата - bin или raw.
  Как быть с памятью СМК я ничего путного придумать не могу.
  ¤
  [Либо в окне просмотра страниц памяти СМК/БК11]
  Мне не нравится сама реализация этого окна, я его реализовал очень не рациональным образом. Его сперва надо переписать по-нормальному, потом навешивать любых кнопочек туда можно будет.
  ¤
  [Так вот и интересовал этот момент - как в железе реализовано?]
  Описание - комментарий к функции void CCPU::Timerprocess(). Вот так и реализовано. При смене делителя счётчик не инициализируется и продолжает уменьшаться с новым делителем. Под сменой делителя понимается изменение только битов 5 и 6, остальные биты не изменяются.
• ? gid - 15.11.2017 19:02
  [Можно запустить обработку диспетчера сообщений]
  Что-то такое мне в голову не приходило. Я знаю что сама идея обрабатывать элементы гуя в простом потоке, как у меня сделано, а не в специальном UI-thread, порочна. Но нормальных примеров, как сделать по-нормальному в интернете я не нашёл. Поэтому в борьбе с дедлоками я понаделал столько локов и флагов. Когда-нибудь надо будет снова всё переделать.
  ¤
  [Встроенный таймер при этом продолжит считать]
  мгновенно с новым делителем или начнёт сначала, зависит от режима работы, ровно так же, как и воплощённый в железе.
  ¤
  [в эмуле неплохо было бы сделать возможность в режиме паузы проца напрямую загрузить/сохранить участок памяти из/в файл(а)]
  Я тоже думал об этом, и не только я, технически это сделать совсем не трудно. Трудно будет, если надо будет загружать/сохранять данные из страниц БК11, которые в данный момент не подключены.
  У меня тогда не было кросс ассемблера, поэтому смысла утруждаться я в этом не видел. Теперь есть, но уже целый год не притрагиваюсь к эмулятору. Нет времени и желания что-то делать урывками впопыхах.
• ? gid - 15.11.2017 13:46
  sleep использовать нельзя по одной простой причине - его параметр задаётся в миллисекундах, а задержку надо делать когда как, -
  на десятки или сотни микросекунд, в зависимости от загруженности фрейма вычислениями видео и звука. Причём виндовсные функции Sleep и т.п. не умеют делать задержку даже на 1мс, только на 10-12мс минимум, и то примерно. Т.к. виндовс не является ОСРВ.
  ¤
  Не знаю какую версию вы смотрите, но в последней доступной версии я исправил функцию UINT CMotherBoard::TimerThreadFunc()
  Косяк, который отмечен в комментарии теперь остался как комментарий к закомментированной старой функции. На будущее, чтоб я не забыл и через несколько лет потом снова не возвращался к неудачному варианту.
  Почему было плохо? А потому, что там был простой цикл do while, где читался QueryPerformanceCounter и вычислялось условие выхода из цикла, что вызывало дикую загрузку процессора почти до 100%. Особенно на ХР.
  ¤
  Какой таймер и какие параметры?
  Таймер 50Гц по вектору 100 - напрямую зависит от частоты кадров экрана, а она старается вести себя независимо и пытается быть 50Гц. Если виндовс сильно занят, то проседает фреймрейт, и пропорционально ему проседает всё остальное - частота кадров, звук начинает запинаться, но вычислительного рассинхрона нет, просто БКшка начинает работать не в реальном времени а в пошаговом режиме. Выполнит фрейм и ждёт, когда виндовс освободит ресурсы, чтобы выполнить следующий фрейм и т.д.
  ¤
  Встроенный ВЕ-таймер ведёт себя как на реальном проце. При изменении параметров работы таймера меняет поведение в соответствии с документацией. Т.к. он напрямую зависит от ТЧ, то при её изменении скорость таймера тоже меняется. TMRclk=CPUclk / 128.
  Ничего не перезапускается, всё работает по жёстко заданному алгоритму. Если я правильно понял вопрос.
• ? gid - 14.11.2017 19:02
  там http://zx-pk.ru/threads/25252-adapter-shiny-mpi-dlya-emulyatora-dvk-1/page3.html
  В последнем посте.
  Только не исходники эмулятора ДВК, а исходники модели процессора, адаптированные под потактовую модель работы шины МПИ.
• ? gid - 14.11.2017 14:30
  [И ищи ее по всем файлам.]
  Ctrl-F и искать во всём проекте - найдётся всё. Правый клик на функции и посмотреть иерархию вызовов - покажет всё, Вижуал студия удобна в этом плане, легко найти и посмотреть всё что угодно в каком угодно большом проекте.
  ¤
  [Нет, чтобы строго .h - объява, .c - реализация]
  Вообще-то так и задумано, и так и должно быть по правилам. Но мне лень копипастить, поэтому все инлайн функции я объявляю и реализую в .h файлах, а так же крохотные функции из одного ретурна там же.
  ¤
  Вот таймер по 100 вектору, в CPU.h
  inline void TickIRQ2()
  {
    m_bIRQ2rq = true;
  }
  вызывается из void CMotherBoard::Make_One_Screen_Cycle() если таймер не замаскирован битом 14 регистра 177662
  ¤
  [если реализовывать 177706-177712 в отдельном потоке]
  Вот поэтому и не надо реализовывать в отдельном потоке. Это просто функция, которая вызывается каждый 128й такт процессора. Поскольку такты эмулируются очень приблизительно, то и таймер работает очень приблизительно. см. как вызывается функция void CCPU::Timerprocess()
  [В сырцах 3.8 в комментах сказано,]
  Там много чего сказано. Иногда там вообще уже неправда. Я когда это замечаю - удаляю или исправляю, но далеко не всегда.
  Так, как сейчас работает таймер - технически правильно, но из-за фундаментально кривой эмуляции самого принципа работы всё работает абсолютно недостоверно.
  ¤
  Там реально надо плюнуть на всё, и писать заново с нуля. У Patrona есть нормальная реализация 1801ВМ1 он даже исходники выклал на zx-pk.ru, но я, когда хотелось и было время, так и не смог разобраться, как выцепить только проц из его эмулятора ДВК, а потом стало не до этого, и до сих пор нет достаточного количества времени, чтобы браться за это.
• ? gid - 14.11.2017 12:09
  m_lockExecuteFrame контролируется. В хедере есть функция IsFrameExecuted(), которая проверяет состояние m_lockExecuteFrame
  Функция вызывается в функциях void CMotherBoard::StopCPU(bool bUnbreak) и bool CMainFrame::SaveMemoryState(CString strPath).
  m_lockExecuteFrame используется для того, чтобы фрейм НЕ выполнялся когда происходят некоторые критичные действия, затрагивающие параметры выполнения фрейма.
  То же самое с m_lockRunning, есть функция IsCPURun(), которая проверяет состояние m_lockRunning. Вызывается в void CMotherBoard::ExecuteFrame(), void CMainFrame::OnCpuResetCpu(), UINT CMotherBoard::TimerThreadFunc()
  m_lockRunning - простой флаг, индицирующий работу процессора. Нужен для синхронизации, чтобы UI и класс CMotherBoard не уничтожался раньше, чем завершится функция ExecuteFrame и отдельный поток TimerThreadFunc (зависит от ситуации: или закрыть прогу или пересоздать конфигурацию)
• ? gid - 13.11.2017 12:37
  В Device - почти низачем. Единственный наследник, который использует этот функционал по назначению - класс Speaker, который использует m_tickCount как счётчик захваченных сэмплов, при эмуляции магнитофона.
  У всех остальных наследников функция NextTick либо не используется вообще, либо используется вхолостую (это значит я просто не закомментировал эту ненужную функцию), либо переопределена для собственных нужд.
  Зачем это нужно было с самого начала - я не знаю, так было, но смысла в этом не было. А я не стал ломать то, что не работало, но не мешало мне.
• ? gid - 13.11.2017 11:01
  Ну, для чего в ООП используются прототипы?
  Поскольку я не фанат ООП и пользуюсь принципами, правилами (и т.п.) ООП только когда без них не обойтись, я так и не понял, в чём фетиш классов-прототипов, кроме как иметь единообразный интерфейс и набор функций-членов класса.
  В конкретной реализации эмулятора - класс прототип такой, какой он есть - бесполезен. Я не стал ломать всё, потому что лень переписывать много наследников.
  Вообще, он не нужен. Его можно удалить, а потом во всех наследниках убрать родителя прототипа, и скопипастить пару функций. Во многих местах и эту пару функций можно исключить за ненадобностью, там функция вызывает другую функцию, а можно просто напрямую вызов делать. В общем возни много, толку - мало. Проще оставить как есть.
• ? gid - 13.11.2017 09:42
  Это был класс прототип. От него наследовалось, да и сейчас наследуется куча классов устройств, хотя я и поломал стройную схему наследования, ибо смысл в ней был только эстетический.
• ? gid - 03.11.2017 10:31
  Не сделает.
• ? gid - 17.10.2017 07:55
  Мне интересно. Но денег нету.
• ? gid - 13.10.2017 14:36
  А вообще никто не помнит или не знает уже.
  У меня ещё есть схема BK Sound card = 2 x AY + Stereo Covox 8bit, и она на плиске EPM70XXS, с исходниками для протеуса и квартуса, тоже кто-то где-то выкладывал, я скачал и просто храню на всякий случай. Наверняка это тоже не SoundDrive.
• ? gid - 12.10.2017 16:50
  Удивительно. Внезапно оказалось, что у меня оказывается есть схема SoundDrive. Я её скачал отсюда и благополучно забыл.
  Берите тут http://gid.pdp-11.ru/f/sounddrive.rar
  Там вортексная схема сконвертирована в скриншот, чтоб и на PC посмотреть её можно было.
• ? gid - 27.09.2017 15:23
  Я имел в виду доки из комплекта документации к БК11 не М, они ещё большая редкость, чем сам БК11 не М. Их то фоткать можно наверное. И я в отличие от модератора Фантом-Саннаты разглядел, что хотел увидеть.
  Просто, качество бумажного носителя, представленного на фотках, оставляет желать лучшего, и сканирование будет не лучше, чем фото, разве что искажений перспективы не будет.
  У меня бумажные доки к БК10 такого же качества, я при сканировании намучился, там сквозь страницу просвечивают буквы с обратной стороны и получается потом много ручной работы по корректировке.
• ? gid - 27.09.2017 11:40
  MM, если ещё что-то надумаете пофоткать, делайте анонс тут пожалуйста.
•   «   1 | ... | 11 | 12 |  13  | 14 | 15 |   »  

?