Электроника БК-0010/0011M

ЛАТ

? Дмитрий - 05.07.2018 16:43
Тогда не буду изобретать велосипед и оставлю все как есть. Пусть будет обычный и повышенный приоритет.
? Дмитрий - 05.07.2018 15:33
Я так понял, что в случаях, где не проверяется bNoPriority, прерывание немаскируемое и произойдет при любом раскладе. А в случаях с прерыванием от таймера и прерыванием от внешнего устройства (priority 6) и VIRQ (priority 7) нужно смотреть на приоритет. Т.е. получается, если у проца выставлен приоритет 7 (наивысший), то произойдет прерывание с VIRQ (из тех, что маскируются), а вот прерывание от внешнего устройства пойдет лесом. А если у проца приоритет 5, то выполнятся оба?
? Дмитрий - 05.07.2018 15:21
>> нужно делать несколько разных входов например векторных прерываний
Нет, я про симуляцию этих приоритетов.
? Дмитрий - 05.07.2018 13:28
Стоп, получается нам тогда лапшу вешали про "если приоритет прерывания выше, чем текущий приоритет проца, то происходит прерывание, иначе нет" и расписывали эти три бита со значениями от 0 до 340? Причем вроде даже Зальцман что-то подобное писал. Помню во второе слово векторов писали 340, 200, 0 - а на самом деле это всего лишь два значения 200 и 0, остальное туфта. И 340 фактически одно и тоже, что и 200. Вот это поворот!
¤
Емнип, bNoPriority показывает необходимость обработки прерывания? Но bNoPriority используется не везде, а только в 6 и 7 приоритете прерывания. Т.е. если делать полноценные 7 уровней, то надо сравнивать текущий приоритет в PSW и приоритет прерывания/вектора, но вектора нам еще неизвестен в коде, где используется bNoPriority. Что-то я запутался...
? Дмитрий - 05.07.2018 11:28
Наткнулся на непонятки с приоритетом процессора. Во времена расцвета БК писали, что в PSW отведено три бита на приоритет - 5,6,7 биты (приоритет 0..7). Заметил, что в эмуле в обработчике прерываний проверяется только 7-й бит - bool bNoPriority = !m_PSW[PSW_P_POS], хотя при инициализации все три бита устанавливаются. Полез в инет - в доках по 1801ВМх пишут, что приоритет в 7-м бите, а 5,6 не используются. Это как так? Выходит у 1801ВМх процов реально есть обычный и повышенный приоритет и никаких других промежуточных?
? Дмитрий - 03.07.2018 10:18
>> инструкции CIS
Нашлись довольно быстро. http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/handbooks/EB-24944-18_Micro_PDP-11_Handbook_1983-84.pdf стр. 363 (355 по документу)
? Дмитрий - 02.07.2018 21:32
Благодарю. Сколько ж там инфы - ее хрен осилишь. Почитал бегло: эти FPU команды бесполезны, а равно как и CSM/TSTSET/WRTCLK (пока, по крайней мере). Насчет CIS припоминаю, что там были команды сканирования строки на определенный символ в обе стороны, еще что-то подобное. Аргументы задавались жестко в определенных регистрах, поэтому сами команды безоперандные. Надо будет порыться в тех пыльных архивах по ссылке.
? Дмитрий - 02.07.2018 11:24
Забыл еще
¤
0070dd CSM
0072nn TSTSET
0073nn WRTLCK
? Дмитрий - 02.07.2018 11:13
Интересуют назначение и описание команд FPU
¤
170003 LDUB
170004 LDSC
170005 STA0
170006 STB0
170007 STQ0
¤
а также инструкций CIS с опкодами 076ххх. Этих команд FPU не нашел в файлах описания системы команд PDP-11, по CIS вообще только мнемоника и опкоды - описания также не могу найти. Сабж вообще есть в природе? CIS хотелось бы реализовать.
? Дмитрий - 15.06.2018 09:30
Могу ошибаться, но вроде М3
? Дмитрий - 14.06.2018 16:19
Я вот щас пишу как раз цикл выполнения команд. Звука пока нет, соответственно буферов тоже. Синхронизация тоже по звуку идет? Надо ставить точное время -20000 (20 мс) для таймера или как в последней версии -10000 * 990 / CPU_FRAMERATE? Я просто не пойму какие таймер вносит задержки, если поставить точное время? И почему сделан периодический таймер вместо однократного? Ведь вы писали про время устаканивания после сработки - там точно не получится отсчитать.
? Дмитрий - 14.06.2018 15:19
То есть waitable timer получается точнее?
? Дмитрий - 14.06.2018 13:46
Только я что-то не понимаю. ExecuteFrame должен вызываться 25 раз в секунду (по 40мс на фрейм), а тут в таймере 50Гц ExecuteFrame вызывается 50 раз в секунду.
? Дмитрий - 14.06.2018 13:32
тьфу, LARGE_INTEGER period = li_clock / 50;
? Дмитрий - 14.06.2018 13:29
Еще один момент. В CMotherBoard::TimerThreadWrapper нет необходимости каждый раз вычислять разницу в мс.
¤
LARGE_INTEGER period = li_clock / CPU_FRAMERATE; // Число тиков в 20мс фрейме
...
do
{
...
QueryPerformanceCounter(&i1);
...
ExecuteFrame();
...
do
{
Sleep(1);
QueryPerformanceCounter(&i2);
}
while (i2 < (i1 + period)); // ловим "перескок" через вычисленную границу 20мс интервала в тиках
¤
в итоге меньше вычислений, не используем плавающую арифметику.
? Дмитрий - 26.05.2018 00:11
2 microxa: А вы не пробовали сделать для FPC модуль кодогенерации для БК? Я в свое время было протянул к этому ручки, но инфы как написать свой backend - никакой, код компилятора вообще не документирован. Надо бы разобраться, но времени нет.
? Дмитрий - 25.05.2018 09:33
>> компилер fpc/ассемблер Фарфорова переделаный
Что за переделанный fpc и асм?
? Дмитрий - 24.05.2018 13:27
>> а что за система BK-проца с 32мя битами, по типу VAX или 68000 (вроде как расширеный PDP)?
Не совсем. 16 32-битных регистров, линейная адресация памяти, полностью сохраненный асм БК, полноценный FPU, префиксы (для 32-битного режима). Простейший видеоадаптер, 3 текстовых режима, 3 режима 256 цветов, 3 режима 65536 цветов. Система команд работает, видео работает. Файловая система будет FAT16/32, в качестве образа винта воткну VHD - удобно будет гонять файлы между БК и PC. Сейчас все собираю воедино, надо погонять тесты.
? Дмитрий - 23.05.2018 19:37
А не проще в обработчике всю эту тонну if-then-else сделать на перечисляемом списке и утоптать в case? Там такая пирамида растет...
? Дмитрий - 23.05.2018 13:05
>> все заменено на SetPSW
и обращениям к m_PSW[]
? Дмитрий - 23.05.2018 13:04
>> заменил PSW массивом булевых переменных - перестало
Я посмотрел новый код CPU.cpp - с признаками все в порядке (на мой взгляд). В реализациях команд все осталось по-прежнему, ибо там использовались функции работы с признаками как с булевыми значениями. Обращений типа m_RON[R_PSW] нет - все заменено на SetPSW.
¤
Кстати, а не мог начаться рассинхрон из-за уменьшившегося времени исполнения фрейма?
? Дмитрий - 23.05.2018 11:07
>> Хотя очень хочется узнать причину феерических глюков в space128
А можно поподробнее про это? Что за глюки, что за space128?
? Дмитрий - 15.05.2018 22:20
Анализатора нет. Таймером, имхо, бесполезно - погрешность будет дай боже (да и команда в ПЗУ - точно начало и конец отсчета не зафиксировать), тогда с такой же точностью проще увеличить константу в столько раз, в сколько раз больше частота процессора относительно "православного" ВМ1, т.е. "пальцем в небо".
¤
Нашел данные по МС 5305 - емнип для него записаны в прошивке SMK время опускания головок (10000(8)) и время перехода с дорожки на дорожку (4000(8)). Для 326-й, опять-таки емнип, 10000 и 10000. Второй параметр 3 мс, т.е. возможно 4000 циклов SOB примерно равны 3 мс. Хотя эти параметры могли быть взяты с большим запасом, тогда вообще непонятно. Мб 3 мс = 3000 циклам, а доп. 1000 накинули для верности. Но задержка опускания головки для 5305 равна 36 мс, что не укладывается. У ТЕАС 15 мс и 6 мс соответственно. Кароче гадание на кофейной гуще.
? Дмитрий - 15.05.2018 16:38
Возвращаясь к драйверу FDD. Как все-таки вычислить время выполнения задержки, допустим, в 10000. циклов SOB в ПЗУ в микросекундах? По тактам я вычислю, но выполнение в ПЗУ быстрее, чем в ОЗУ. Переделывать на битовые флаги все же не комильфо. Пусть все останется таким, каким придумали изначально, надо только с задержками разобраться.
? Дмитрий - 12.05.2018 21:13
>> если пытаться применить к БК стандарт VESA, то и выйдёт полная чушь, неужели не понятно?
Если к БК10/11, то ессно нет смысла, но я не о них говорю. В том же Бустере и в БК12 будут стандарты VESA. Я просто не стал ради пары вопросов создавать новую тему.
? Дмитрий - 08.05.2018 11:17
C 3/4 МГц нет особых проблем в задании тактовых задержек. А вот мне с моими 100 МГц выдерживать 10 нс на такт нет вообще никаких вариантов, кроме фреймового. И вообще, как народ писал эмули той же плойки на РС или эмули Ведроида - там же далеко за 100МГц частоты. И ведь работают как-то. А потактовой реализацией ВМ1 от Patron вообще мрак - я вижу текст, вроде написано (местами) понятно, но я нихрена не понимаю что там и как делается. Ощущаешь себя открывшим трактат на китайском языке.
? Дмитрий - 08.05.2018 01:22
>> чтобы было быстрее, а не точнее
Блин, весь эмулятор построен "лишь бы работало" :)
? Дмитрий - 07.05.2018 18:54
Вопрос про таймер, который 177706/10/12. У Зальцмана написано, что частота таймера совпадает с частотой проца. А в эмуле CCPU::Timerprocess вызывается каждый 128 такт. Примерный период, вычисленный на нескольких БК, у Зальцмана 42.9 мкс. В итоге с макс. множителем цикл получается 180 сек. Верны ли данные зальцмана?
? Дмитрий - 06.05.2018 14:31
>> 1) Разница потому, что ноги растут от телевизионных стандартов 50 и 60 Герц.
Стоп-стоп. Параметры 640х480 я взял именно 60Гц, стандарт VESA. И именно в пределах этого режима разные длительности кадра. Вычисленная длительность строки верная, а вот длительность кадра - нет. Почему так и причем тут 50 и 60Гц, если я взял именно 60Гц? Вносятся какие-то доп. задержки? Или 31.75 мкс - это длительность строки именно самого изображения, без учета гашений, бордеров и прочего?
¤
http://caxapa.ru/thumbs/361638/DMTv1r11.pdf стандарт, режим на 17 стр.
? Дмитрий - 05.05.2018 15:43
Что-то я не волоку в параметрах видеосигнала. В БК при 256х256 на строку отводится 64 мкс. По стандарту там 52 мкс само изображение и 12 мкс на гашение для перехода на следующую строку. Итого 64 мкс * 256 строк = 16384 мкс на весь кадр. Кадр 20 мс. Обратный ход луча - 20000-16384=3616 мкс. В стандарте сказано, что 80% времени задействовано на вывод информации. В БК получается ~82%. Сходится. Это для 256х256. А для 512х256 тоже самое или нет?
¤
Далее. Если я правильно понял из стандарта, то у 640х480 горизонтальная частота 31,5кГц, т.е. за секунду в таком разрешении адаптер может выдать 31500 строк или 31500/60 = 525 на кадр. 1 строка выводится за 1/31500 = 31.75 мкс, 480 строк - за ~15238 мкс. Если взять пиксельную частоту у этого режима 25.175 Мгц, то 640х480 = 307200 пикселей и с такой частотой эти 307200 пикселей будут выведены за ~12203 мкс. Почему такая разница? По стандарту VESA кадр в этом режиме 16.7 мс.
? Дмитрий - 28.04.2018 12:42
Модульный компьютер на КР1801ВМ2 в корпусе Mini-ITX - https://geektimes.com/post/300383/
? Дмитрий - 20.04.2018 15:48
У Вортекса, емнип, даже загружаемые модули были. В свое время начинал писать модуль трансляции для него, чтобы прямо из Вортекса асм собирать. Да все наработки (и не только эти) благополучно похоронил на умершем винте...
? Дмитрий - 19.04.2018 20:33
>> ничего в "инсульте" такого нет
Разве не в ней переключение буферов (или палитр) было для достижения каких-то эффектов? БК12 такого не умела (теперь, выходит, умеет).
? Дмитрий - 19.04.2018 15:36
>> Я Инсульт для примера привел
Да я, в общем-то, тоже для примера. Дему пару раз запустил и забыл. А на работы по адаптации к ней софта/железа вагон времени убит. Кто-нить наваяет еще какую дему, в которой неизвестные доселе ухищрения будут и придется опять полгода допиливать, чтоб и эти эффекты на 12-й казало как на родной БК. И еще не факт, что при допиливании нового не "сломают" эффекты того же Инсульта и др. дем.
? Дмитрий - 19.04.2018 11:01
И возникает вопрос - на пуркуа??? Не Инсультом едины...
? Дмитрий - 13.04.2018 09:49
>> Только у суперпрофи есть овердохера свободного времени, чтобы убить его на машкоды
Я бы добавил "... при отсутствии других средств разработки"
? Дмитрий - 07.04.2018 23:34
Проверил. Работает. Сделал примерно так:
¤
enum Thread_Status
{
ts_Worked,
ts_Suspended,
ts_Terminated
};
¤
LockVarType LT;
Thread_Status TS;
HANDLE hThread; // дескриптор потока
...
¤
UINT TimerThreadFunc()
{
HANDLE CurThread;
Thread_Status Status;
¤
CurThread = GetCurrentThread();
// тут запускаем цикл выполнения
do
// сразу же проверяем выставленный статус потока
while (!LT.IsLocked()); // ждем, если в этот момент менятся статус
LT.Lock();
Status = TS;
LT.Unlock();
// проверяем, что делать с потоком
switch (Status)
{
case ts_Suspended:
SuspendThread(CurThread); // поток поставлен на паузу - паузим сами себя
break;
case ts_Terminated: return 0; // выходим, поток остановили
}
...
// далее выполняем поток как обычно
...
while ...;
}
¤
Создаем приостановленный поток, выставляем TS = ts_Worked, в нужном месте ResumeThread(hThread). Поток запустился. Если нужно запаузить/завершить рабочий поток:
¤
if TS = ts_Worked
{
while LT.IsLocked() // пока залочено - ждем
{
}
LT.Lock();
TS = ts_Suspended; // меняем статус (или ts_Terminated)
LT.UnLock();
}
¤
Если надо запустить приостановленный поток:
¤
if TS = ts_Suspended
{
TS = ts_Worked; // лочить не надо - поток неактивен
ResumeThread(hThread);
}
¤
Итого имеем: проверка и выполнение действий с потоком происходит в начале цикла, когда новая итерация цикла еще не начата, либо предыдущая гарантированно отработала.
¤
PS: Не знаю написал ли на Си правильно - по написанию я пока с ним на "мама мыла раму", а не на "о сколько нам ошибок трудных..."
? Дмитрий - 07.04.2018 16:17
Возникли пара вопросов по поводу потока CMotherBoard::TimerThreadFunc. Как лучше сделать, чтобы при паузе или завершении потока извне гарантированно завершился цикл эмуляции команды? Юзать флаги извне? Типа bool Terminated, Suspended. Или добавить лок и лочить в TranslateInstruction пока выполняется 1 команда. Либо забить на команду и ждать окончания выполнения ExecuteFrame - там лок уже есть. И можно ли внутри потока юзать Suspend/Terminate для паузы/остановки самого себя? Последнее пока проверить не могу, времени мало.
? Дмитрий - 26.03.2018 17:30
2 Voland: Вы, не доделав толком бустер и пристнопамятный БК12, кидаетесь на следующий проект. По бустеру хоть черновая документация с примерами написана, а по БК12 нет ни ТТХ, ни документации, ни новостей, ничего... Прошло уже лет 8 и все также туманно. "За двумя зайцами..."
? Дмитрий - 21.03.2018 10:03
>> Компьютер мечты будет ещё более мертворожденным, чем Неон, и софт писать некому...
Как говорится, дайте железо, софт будет. На БК тоже софта не было, однако энтузиастов это не остановило.
? Дмитрий - 18.03.2018 16:54
И для 3 и 5 тоже.
? Дмитрий - 16.03.2018 21:20
Непонятка в выборке аргумента. Команда MOVB #1,R0. Константа 1 записана как word. По Get_Src_Arg мы получим в m_datarg = GetByte(m_nSrcAddr) эту единицу, а адрес PC увеличится на 1 в get_arg_addr. Но я не вижу где идет увеличение PC как адреса-источника еще на 1, чтобы сместиться на следующую команду?
? Дмитрий - 16.03.2018 13:54
Насчет признаков в виде булевых переменных. При 3 млн. тактов/фрейм удалось сократить время выполнения фрейма на 3 мс (с 19 до 16 мс). Но Дельфя по сравнению с Сями тормознее. Вполне может статься, что на 3/4 МГц прирост будет мизерный, но Си может вытянуть оптимизацией. Позднее перепишу реализации команд ВМ1 на асм, посмотрим сколько там удастся выиграть.
? Дмитрий - 14.03.2018 18:01
Еще непонятка.
¤
if (bInterruptMode) // HALT mode interrupt
{
m_bTwiceHangup = (bCanTwiceHangup && nInterruptVector == 2);
m_pChip->SetWord(0177676, m_RON[R_PSW]); //вот это-то и вызывает прерывание по вектору 4
m_pChip->SetWord(0177674, m_RON[R_PC]);
m_bTwiceHangup = false;
nInterruptVector += 0160000; //Таки да, у 1801ВМ1 действительно тут константа 0160000
m_RON[R_PC] = GetWord(nInterruptVector);
m_RON[R_PSW] = (GetWord(nInterruptVector + 2) & 07777) | PSW_HALT;
}
¤
Для чего nInterruptVector увеличивается на 160000? В m_RON[R_PC] и m_RON[R_PSW] считается хрень - не с адреса вектора прерывания, а с ПЗУ FDD. Или в БК этот кусок никогда не будет выполняться? Тогда непонятно зачем он тут.
? Дмитрий - 14.03.2018 17:15
Да и терминальчик - так, в голову первое что взбрело...
? Дмитрий - 14.03.2018 17:14
Чё сразу убивать? :) Я про эмулятор говорю, а не про железку - железка меня не интересует.
? Дмитрий - 14.03.2018 14:38
>> Какие "для других целей"?
Ну, к примеру, как эхо-теминальчик на РС - сохранить всю текстовую информацию, выводимую на экран.
? Дмитрий - 14.03.2018 13:49
>> они будут попадать сюда, прям через wifi
А если без этой штуки? Так сказать для других целей?
? Дмитрий - 14.03.2018 13:13
>> функцией вывода содержимого PSW на экран
В принципе верно, но можно же сделать и вытаскивание состояния признаков не с PSW, а тоже с проверки булевых переменных для вывода? Тогда PSW как член класса будет не нужна вовсе, а формирование PSW будет сразу в FALU.
¤
2 BD: Возник вопрос - вот сделан в эмуляторе регистр 177560 (и сопутствующие) - а куда попадающие в него данные будут улетать из эмулятора? Нужен же виртуальный СОМ-порт, куда будут отправляться данные, а софтина на РС будет из этого порта их читать.
? Дмитрий - 14.03.2018 00:35
Возник вопрос в плане быстродействия реализации команд. Не быстрее будет признаки не сразу записывать в переменную через логические команды, а хранить булевы переменные под них, Т-разряд и прочее? А слово PSW формировать непосредственно в реализации MFPS. Ведь во время эмуляции команд каждая работает с признаками, а MFPS может быть вообще не вызвана.
« 1 | 2 | 3 | 4 | 5 | ... | 9 | »