Попробуй в 0.03b. Там есть маппинг памяти PPU, а так же исправлена ошибка отсутсвия поддержки FPU-инструкций, из-за чего бейсик тоже вешался.
Попробуй в 0.03b. Там есть маппинг памяти PPU, а так же исправлена ошибка отсутсвия поддержки FPU-инструкций, из-за чего бейсик тоже вешался.
Провел кое-какие исследования на реале. Оказалось, что вы совершенно правы:Сообщение от Alex_K
Итого мы имеем результат - в нашем процессоре как класс отсутствуют циклы байтовой записи в память. Вместо них идут циклы RMW. Кстати, если вы заметили, цикл RMW PPU для словных и байтовых команд отличается на 4 такта из-за того, что ОЗУ PPU 8-битное, и слова записываются в два приема по 8 бит.Код:Сравнение времени выполнения байтовых и словных команд на CPU и PPU: Мнемоника-1 CPU PPU Циклы Мнемоника-2 CPU PPU Циклы ------------------------------------------------------------------------------ MOV Rn,(Rn) 33.13 36 W MOVB Rn,(Rn) 40.62 52 RMW CMP Rn,(Rn) 27.90 40 R CMPB Rn,(Rn) 27.90 40 R BIT Rn,(Rn) 27.90 40 R BITB Rn,(Rn) 27.90 40 R BIC Rn,(Rn) 40.62 56 RMW BICB Rn,(Rn) 40.62 52 RMW BIS Rn,(Rn) 40.62 56 RMW BISB Rn,(Rn) 40.62 52 RMW XOR Rn,(Rn) 40.62 56 RMW ADD Rn,(Rn) 40.62 56 RMW SUB Rn,(Rn) 40.62 56 RMW CLR (Rn) 33.13 36 W CLRB (Rn) 40.62 52 RMW COM (Rn) 40.62 56 RMW COMB (Rn) 40.62 52 RMW INC (Rn) 40.62 56 RMW INCB (Rn) 40.62 52 RMW DEC (Rn) 40.62 56 RMW DECB (Rn) 40.62 52 RMW NEG (Rn) 40.62 56 RMW NEGB (Rn) 40.62 52 RMW TST (Rn) 27.90 40 R TSTB (Rn) 27.90 40 R ROL (Rn) 40.62 56 RMW ROLB (Rn) 40.62 52 RMW ROR (Rn) 40.62 56 RMW RORB (Rn) 40.62 52 RMW ASR (Rn) 40.62 56 RMW ASRB (Rn) 40.62 52 RMW ASL (Rn) 40.62 56 RMW ASLB (Rn) 40.62 52 RMW ADC (Rn) 40.62 56 RMW ADCB (Rn) 40.62 52 RMW MFPS (Rn) 40.62 52 RMW SWAB (Rn) 40.62 56 RMW SXT (Rn) 33.13 36 W
Уже значительно лучше, но символ в слове "Circle" также пропадает. Да и во время прохождения теста довольно много ошибок.
Кстати по поводу пропадающего символа. В UKNCBTL он стал пропадать после того, как была причесана обработка прерываний. Раньше фактически было так - обработано прерывание, затем команда. Потом стало так, как должен обрабатывать процессор - сначала все незамаскированные запросы на прерывание, а затем, когда не осталось запросов - уже команда.
В УКНЦ при выводе на экран (канал 0) есть ошибка, связанная с переполнением буфера. Может возникать ситуация, когда производится обработка очереди (полной) и возникает запрос на прерывание канала 0. Я этот момент уже описывал. Ярко он проявился на программе от Patron по подсчету CPS, проявление было как на реальной машине, так и на эмуляторе.
Может у тебя турбобейсик не такой? У меня ниче не пропадает)
Скрытый текст
[свернуть]
Так же пропадает, правда не всегда, так 50 на 50. Попробуй выполни какой-нибудь короткий тест, например Colors Demo, и выйди после этого в меню нажатием любой клавиши.
А, да. Может не 50/50, но за несколько раз один раз выпала. Причем одна и та же буква. На UKNCBTL та же выпадает? Интересно, значит у нас у боих неправильно что-то эмулируется)
У реальной обработки прерываний есть ещё один небольшой аспект - запрос прерывания начинает обслуживаться строго через одну команду после его выставления.
Т.е. наличие запроса на прерывание (при разрешённых прерываниях) ещё не означает, что запрос будет обслужен - нужно проверить, сколько команд назад этот запрос был выставлен.
Речь у меня шла немного про другое, про одновременное выставление запросов на прерывание несколькими устройствами, и блок обработки прерываний должен сперва обработать все незамаскированные прерывания, а уж потом исполнять команду.
Но вопрос про задержку поставлен совершенно правильно. В UKNCBTL такой задержки нет. Если по каналу 0 что-то передается для ПП, то после записи со стороны ЦП, со стороны ПП сразу же возникает запрос на прерывание, а не должно, действительно, только при исполнении следующей команды. Аналогично, если байт был прочитан со стороны ПП, то со стороны ЦП требование для записи очередного байта должно возникнуть не сразу.
Тут скорее всего такое дело, что процессор читает регистр запросов на прерывания во время исполнения команды. Поэтому установка бита разрешения прерывания вызовет прерывание не после этой команды, а после следующей. Из-за этого и советуют бит разрешения прерывания очищать при запрещенных прерываниях, чтобы не возникало ситуации ошибки приема адреса вектора прерывания.
Обновил версию до 0.04a.
Изменения такие относительно 0.03a:
Сделан маппинг памяти PPU, поддержка FPU-инструкций, исправлены циклы Write->RMW для байтовых команд (спасибо Alex_K), сделана смена палитры RGB->GRB->Black/White по клавише '~', клавиша АР2 перенесена с '~' на 'ESC'.
Теперь работает Турбобейсик, корректно работает графика в 'спрайтовом режиме' и заливка там, где она не работала.
Однако КЦГД стал ругаться в консоли при нажатии '<--', когда стирать в строке уже нечего. Появилось это после изменения циклов байтовых команд с W на RMW. КЦГД так же работает, но просто ругается.
---------- Post added at 18:41 ---------- Previous post was at 18:31 ----------
Понятно, теперь он читает регистр, в который раньше только писал. Ниче страшного)
Значительно лучше, даже буковка почти перестала пропадать.
Даже могу сказать почему. Ругаться будет и после нажатия неправильной комбинации, которую не поддерживает SL. Просто SL в этом случае выдает звуковой сигнал управляющим кодом 7, а КЦГД сам пищать не умеет, он просто дает клавиатуре МС7004 команду подать звуковой сигнал. Общение с клавиатурой сделано через 1801ВП1-065. У неё регистры данных и читаются и пишутся в обоих направлениях с выдачей RPLY, просто в приемнике запись уходит в никуда, а в передатчике по чтению читается адрес вектора прерывания приемника.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием