Скорость самой памяти мне ничего не говорит. Надо было знать число циклов доступа к памяти чипсета УКНЦ, а я его не знал.Сообщение от MiX
Скорость самой памяти мне ничего не говорит. Надо было знать число циклов доступа к памяти чипсета УКНЦ, а я его не знал.
Ларчик открывается достаточно просто - быстродействие УКНЦ, в части Главного Процессора ( ГП ) при пользовании ПЗУ ( выборка - менее 400 нс ) - более 600 т. оп/сек ( команды 000240, 010001 и т.п. ). А вот быстродействие ГП при выполнении команд из ДОЗУ - в районе быстродействия БК0011М. Это объясняется чрезвычайно неконструктивным выполнением обвязки контроллера ДОЗУ - для экономии площади печатной платы. А если точнее - обвязки нет совсем, мультиплекс адресов ( для БИС ДОЗУ ) выполняется в самой медленной БИС БМК, да с задержками на 1 такт для верности выставленных данных, и при работе на 3 канала - ГП, ПП и Видеовывод.
К сожалению, идея вынести мультиплекс адресов к разработчикам УКНЦ пришла только годом позже ( 1987 ), когда уже пошла серия, и что-либо менять означало боооольшие потери ( в деньгах и репутации ).
*
Кстати, здесь иногда появляется разработчик УКНЦ, он же разработчик БК0010.
*
УКНЦ было продано на порядом меньше, чем БКшек - виду того, что БКшки начали массово продавать с начала 1985 г. ( 550 руб ), а УКНЦ появились в "Электрониках" в районе 1988 г, и сразу по космической цене - в районе 1600 руб без дисковода ( сам дисковод 6022 стоил 1850 руб ). Зарпалата техника-практиканта ( в ОКБ Э. ) в 1987 г. была 120 руб минус НДФЛ. Инженер 1 категории получал тогда в районе 300 руб, колбаса категории "Велком" из натурального мяса стоила 3.70 руб, просто из мяса - 2.90, а аналог сырокопченой Велком, да существенно получше качеством - 9 р.10 коп., и считалась чудовищно дорогой, но зато весьма качественной.
Пенсии были в границах 72 руб...120 руб ( без учета ветеранов куликовской битвы ).
Блог : http://collectingrd.kxk.ru/ . В ЛС прошу не писать, все сообщения [email protected]
Проверил на обоих эмуляторах простейшую программу на Бейсике: FOR I=1 TO 10000/NEXT I. В EmuStudio скорость оказалась выше почти в 2 раза! - 4,3 с вместо 8 с у UKNCBTL. Частота кадров на мониторе у меня, конечно, 60 Гц. Однако, разница большая. Я, правда, всегда тестировал на UKNCBTL - надеюсь, он близок по скорости к реальному УКНЦ?
Хорошо бы всё-таки проверить скорость этого теста ВМ3 на реальном ПК, чтобы знать, насколько он отличается от эмуляторов.
Кстати, тесты на Бейсике не так уж бесполезны: всё же Бейсик - это хороший пример реальной и довольно сложной программы, работающей в реальных условиях совместного функционирования ЦП и ПП, а не просто искусственный тест. Кстати, тесты машинных команд на UKNCBTL я запускал, и они показывали точно такие же результаты (с учётом небольшого естественного разброса), как и результаты на реальном УКНЦ из соответствующей темы на этом форуме.
Только вот результаты эти, опять же, очень сомнительны в отношении скорости реальных программ на УКНЦ - по-крайней мере того же вильнюсского Бейсика.
Почему при таком явном преимуществе ЦП УКНЦ над БК-0010 в искусственных тестах (в 2-2,5 раза) скорость вильнюсских Бейсиков, использующих одинаковую точность вычислений с плавающей запятой (а для БК - это уже упоминавшийся 9-килобайтный упрощенный Бейсик, загружаемый в ОЗУ), почти одинакова?
Может быть в искусственных тестах ЦП гораздо меньше тормозится со стороны ПП и контроллеров? И вообще, есть ли какая-то существенная зависимость скорости работы ЦП от работы ПП или, скажем, видеоконтроллера? Может ли скорость ЦП отличаться в разных условиях примерно в 2 раза?
---------- Post added at 20:26 ---------- Previous post was at 20:12 ----------
Спасибо за разъяснения. Однако хитрость здесь в том, что тесты времени выполнения машинных команд (а по ним на форуме есть отдельная большая тема) выполняются не в ПЗУ, а в ОЗУ! И они показывают быстродействие ЦП на самых простых командах в районе 667 тысяч оп/с! Т.е. около 12 тактов на команду, как и на БК.
Но, похоже, что реальные программы (тот же Бейсик) работают намного медленнее (примерно в 2 раза!) - действительно, на уровне БК-0011.
Интересно, почему такая разница между искусственными тестами и реальными программами (Бейсиком)?
---------- Post added at 20:29 ---------- Previous post was at 20:26 ----------
А вот я очень отчётливо помню (хотя, конечно, могу ошибаться, что видел в каком-то журнале (Информатика и образование?) цену что-то около 998 рублей. Могло быть такое? И ещё встречал цену вроде 1224 руб.
---------- Post added at 20:40 ---------- Previous post was at 20:29 ----------
А можно подробнее, что означает нешустрая графика? Ведь у него практически аппаратные скроллинги во всех направлениях, плюс плоскостная структура видеопамяти, плюс возможность выбора любого горизонтального разрешения для каждой строки, плюс палитры и т.д. А вот, кстати, не подскажите, можно ли уменьшать вертикальное разрешение в целое число раз (до 144, 96 и т.д. строк), повторяя одну строку 2, 3 и т.д. раза подряд? Насколько я понял, можно? Так ведь более крутой видеосистемы у дешевых ПК просто не было! И скорость копирования в экранную память в районе 250-300 тысяч байт/с - это разве нешустро?
Про сравнение скорости работы UKNCBTL и реальных машин можно посмотреть здесь:
https://code.google.com/p/ukncbtl/wiki/Compatibility
Тайминги выполнения команд подводились так, чтобы тесты давали более близкую к реальности картину, но без правильной эмуляции задержек на шине -- правильных таймингов конечно не будет.
Что касается количества выпущенных машин УКНЦ -- это в районе 310 тысяч, но конечно почти все в составе КУВТ, в свободной продаже было довольно мало машин, да и слишком дорогие.
Скроллинги -- можно сказать что только по вертикали, достигается тем, что меняется один указатель на следующую строку экрана (через ПП), так что можно сказать -- вертикальный скроллинг мгновенный.
Скроллинг по горизонтали возможен только на 8 пикселей сразу, но для этого нужно поменять начала для всех строк, которые скроллируются. И сделать это через ПП.
Плоская структура видеопамяти -- нет, не так. Три плана памяти, пиксел находится сразу в трёх (три бита, 8 цветов), причём от ЦП доступны только два, третий доступен только из ПП. Для изменения даже одного пиксела нужно изменить значения в трёх планах памяти (можно в двух если вам хватит 4 цвета, или в одном если хватит двух цветов). Так что это медленнее в 2-3 раза чем плоская память (как у БК).
Масштабирование по-вертикали -- сейчас точно не скажу, но по-видимому, это возможно. Другое дело что там всего 288 строк, поэтому смысла масштабировать по-вертикали вообще довольно мало.
И УКНЦ это НЕ дешёвая машина, БК гораздо дешевле.
Выигрывает она за счёт бОльшей частоты процессора и если удаётся задействовать оба процессора сразу.
На мой взгляд, видеосистема у УКНЦ странная. По сути, хоть и простой, но отдельный видеопроцессор, но это преимущество почти не использовано.
---------- Post added at 16:35 ---------- Previous post was at 15:48 ----------
То что писалось тогда в прессе могло сильно отличаться от реальности )
Но даже цена БК в 650-750 руб была в 2-3 раза выше зарплаты инженера, что уж говорить про УКНЦ. Кроме того, даже имея нужную сумму, нужно было не потратить её на новый телевизор/стиралку/тряпки жене, а целенаправленно искать в магазинах именно компьютер. Классов УКНЦ не хватало для замены классов БК -- заводы не выдавали нужного количества (см. ссылку ниже), так что думаю в рознице машина была редко.
http://www.computer-museum.ru/histso...rucom_2011.htm -- вот тут есть некоторые цифры по выпуску машин
Спасибо за ссылку. Получается, что скорость выполнения регистровых команд в UKNCBTL в точности совпадает со скоростью на реальном ПК, а вот команды, работающие с памятью, выполняются немного быстрее – в тесте команда сложения регистр-память выполняется на 14% быстрее, но в реальных программах, очевидно, разница в скорости выполнения на эмуляторе и реальном ПК не должна превышать примерно 10% (а может, и 5%, учитывая, что регистровые команды явно должны преобладать в реальных программах). В любом случае, скорость UKNCBTL, похоже, довольно близка к оригиналу.
Жаль, что никто пока не нашёл времени протестировать-таки этот несчастный бейсиковский бенчмарк ВМ3 на реальном УКНЦ (а лучше бы весь ряд тестов ВМ1-ВМ8 (это не так долго – я перемерял на них скорость множества эмуляторов разных ПК) плюс Calculator Benchmark (8 ферзей, см. Ютуб)). Это дало бы сразу два важных результата:
1) Разницу в скорости между UKNCBTL и реальным УКНЦ, причём измеренную не на искусственном тесте, а при работе реальной сложной программы «полукомпилятора» Бейсика. А это позволило бы скорректировать результаты тестов УКНЦ (сделанных на эмуляторе – см. тот же Calculator Benchmark в Ютубе), умножив их на соответствующий коэффициент.
2) Степень торможения ЦП УКНЦ в реальных условиях работы Бейсика (это можно достаточно точно определить при сравнении результатов на УКНЦ и БК-0010 или 0011М).
Правда, не совсем понятно, какие версии Бейсика наиболее корректно брать для сравнения УКНЦ и БК: как я уже не раз писал, вроде бы получается, что наиболее близки обычный вильнюсский Бейсик УКНЦ (размером 28-30 Кбайт) и упрощенный вильнюсский Бейсик для БК-0010 (9 Кбайт) - у них одинаковые или почти одинаковые (с учётом дополнительных команд у процессора ВМ2) алгоритмы работы с вещественными числами. Однако ещё лучше было бы взять какие-то близкие по размеру и возможностям версии. Может быть, кто-нибудь подскажет – есть ли на УКНЦ Бейсик, полностью аналогичный 24-килобайтному Бейсику БК-0010-01 в плане обработки чисел с плавающей запятой (т.е. поддерживающий двойную точность вещественных чисел (64 бита, а не только 32) и выполняющий все вещественные вычисления только в режиме двойной точности, в том числе и с константами и переменными одинарной точности (из-за этого на БК вычисления с одинарной точностью выполняются иногда даже медленнее, чем с двойной (!) – видимо, за счёт дополнительных затрат времени на «конвертацию» чисел из одинарной точности в двойную и наоборот). Может быть, я что-то пропустил, но я такой версии не нашёл, хотя вариантов Бейсика на УКНЦ много.
И ещё один вопрос на тему цен, который «не даёт мне покоя»: была ли какая-то практика использования УКНЦ без дисковода и сети, а с обычным магнитофоном. То есть была ли вообще возможность загружать программы на УКНЦ с магнитофона (хотя бы игры), и если была, то пользовался ли этим кто-то на практике? Дело в том, что я никогда ничего не слышал насчет использования УКНЦ в домашних условиях без дисковода, но ведь такая возможность предусмотрена и в аппаратуре, и в ПО УКНЦ (есть же в начальном меню загрузка с магнитофона). Я понимаю, что в УКНЦ без дисковода вряд ли был смысл (если уж требовался самый дешевый вариант, то гораздо правильнее было бы приобрести домой тот же БК или Спектрум или другой советский ПК, для которого было полно программ на кассетах), но от этого сильно зависит, так сказать, ценовой класс УКНЦ. При работе с магнитофоном его вполне можно отнести к дешевым ПК (даже 1600 руб – это цена на уровне дорогих моделей 48-килобайтных (!) Спектрумов). Но при условии, что обязательно нужен дисковод, затраты получаются совсем другие: 1600 р сам УКНЦ + порядка 1500-2000 руб. за один дисковод (как справедливо пишет ММ, в конце 80-х обычный 5-дюймовый дисковод в «Электронике» стоил аж 1850 руб) + контроллер (тут я цену не представляю даже приблизительно, хотя, например, контроллер для БК мог стоить близко к цене самого БК!) + БП (ну это совсем недорого относительно всего остального). В сумме – порядка 4000 рублей (без монитора и с одним дисководом!). Но ведь тот же Агат стоил в минимальном варианте около 3900 руб. (причём вроде бы с цветным монитором и двумя дисководами). Тогда выходит, что как бы недорогой УКНЦ реально обходился дороже Агата, который хотя и уступал по большинству параметров УКНЦ, но был же «почти совместимым» с Apple II, и на него было адаптировано очень много хороших программ и игр с Яблока, да и специально для него написано немало. Впрочем, и другие ПК с дисководами тоже обходились дороговато, хотя и дешевле за счёт меньшей цены самого ПК.
По поводу структуры видеопамяти вы абсолютно правы – под плоскостной структурой я имел в виду именно это: три плана (плоскости), в каждом из которых хранится один бит логического цвета точки.
А вот согласиться с «медленностью» 3-плановой структуры я никак не могу – всё как раз совсем наоборот! Этот вопрос я хорошо изучил ещё во времена программирования на «Векторе» и БК.
Если нам нужно просто скопировать в видеопамять какой-то, скажем, 4-цветный фрагмент типа части фона размером 16х16 точек (на практике, увы, по указанным вами причинам (чтобы упростить программирование, задействуя только ЦП) многие игры для УКНЦ были именно 4-цветными), то никакой особой разницы по скорости между БК и УКНЦ нет: что на БК мы копируем 16х4=64 байта (в каждом байте видеопамяти 4 точки по 2 бита на каждую), что на УКНЦ копируем 2 (число плоскостей)х16х2(16 точек=2 байта в ширину)=64 байта, просто расположены они в разных областях (плоскостях) памяти. Откуда вы взяли 2-3-кратное отставание УКНЦ?
А вот если мы хотим, например, программно сдвинуть какую-то область экрана (скажем, сделать медленный горизонтальный попиксельный скроллинг фона), то на УКНЦ нам достаточно сдвигать лишь одну плоскость (да, при этом будет сдвигаться только одноцветный фон, но это может быть вполне приемлемо), а на БК вынуждены в любом случае сдвигать вдвое большее число байтов (поскольку никаких «планов» нет, цвет точки хранится в соседних битах одного и того же байта), даже если нам было бы достаточно сдвига монохромного фона. Более того, для горизонтального сдвига на одну точку на УКНЦ достаточно выполнить одну команду сдвига (поскольку 1 бит соответствует одной точке), а на БК – два сдвига! (1 цветная точка – это 2 последовательных бита). То есть в случае плавного горизонтального скроллинга монохромного фона на БК, выходит, нужно выполнить ВЧЕТВЕРО больше команд сдвига, чем на УКНЦ!!! (Чтобы лучше понять, что происходит, представим, что мы сдвигаем одноцветный объект шириной 8 точек: в случае с УКНЦ этот объект имеет ширину 1 байт, и для сдвига его на одну точку достаточно выполнить одну операцию сдвига в нужную сторону (с учётом переноса или без учёта – в примере это неважно); у БК этот объект будет шириной ДВА байта (4 точки на байт), поэтому нужно будет сдвинуть, во-первых, не один байт, а два, и, во-вторых, каждый по 2 раза – сначала сдвинуть первый байт, затем второй байт вместе с переносом, затем снова первый и снова второй!).
Соответственно, даже если мы сдвигаем и на БК, и на УКНЦ 4-цветный фон, УКНЦ снова имеет преимущество практически в 2 раза!
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Продолжение
Вот вам и медленная «плановая» видеопамять. Конечно, у «последовательного» кодирования цвета (БК, CGA, Amstrad CPC, BBC Micro и т.д.) есть и некоторые достоинства – например, у БК при побайтовом горизонтальном сдвиге шаг сдвига меньше, чем у ПК с плоскостной организацией (4 точки вместо 8, а у Amstrad CPC в 16-цветном режиме - вообще 2 точки), т.е. в большем числе случаев можно задействовать не медленный побитовый сдвиг, а быстрый побайтовый (с другой стороны, у ПК с битовыми планами скорость побитного сдвига сравнима со скоростью побайтного сдвига у ПК с «последовательным» цветокодированием
К тому же, поскольку скорость отображения цветных картинок у ПК с организацией экрана наподобие БК практически не отличается от скорости отображения монохромных картинок и занимаемый в памяти объем тоже (что само по себе – большой недостаток; даже звучит всё это странно – ведь логика подсказывает, что монохромные картинки должны быть меньше по объему и поэтому вроде должны отображаться быстрее
У «плановой» организации видеопамяти есть и ещё одно интересное свойство (особенно в сочетании с программируемой палитрой) – очень легко реализовать точное наложение спрайтов на сложный фон. Если на БК, Спектруме, Амстраде, ИБМ с ЦГА и других ПК без поддержки аппаратных спрайтов наложение спрайтов на фон – это целая проблема (нужно хранить в памяти кроме спрайта ещё теневую маску такого же объема, в общем случае перед наложением спрайта надо скопировать фон в буфер (а в следующем цикле наложения спрайтов сначала восстановить фон из буфера), потом накладывать маску логическими операциями (очищать фон под спрайтом), накладывать сам спрайт логическими операциями и т.д. – это ж с ума сойти можно!), то на ПК с «плоскостями» да ещё и программируемой палитрой можно, немного пожертвовав опять же многоцветностью картинки, накладывать спрайты самым примитивным образом – простым копированием их в видеопамять, без всяких теневых масок и извращений с буферами и логическими операциями (т.е. не только в разы быстрее, но и в разы менее затратно по памяти!).
Например, на «Векторе» (а я уж, простите, лучше разбираюсь в нём, чем в УКНЦ) очень часто использовался режим, когда два битовых плана отводились для фона (4 цвета) и два плана – для спрайтов (ещё три цвета – четвертый прозрачный), что позволяло отображать очень даже приятную 7-цветную картинку (Амбал, Гротоход, Step&Jump и др. игры) с прекрасными, очень быстрыми спрайтами без всяких чёрных или цветных квадратиков по краям спрайтов. Аналогично использовался режим 1 цвет спрайтов на 8-цветном фоне (например, в «Полёте», а можно было и наоборот – 7-цветные спрайты на одноцветном фоне). В общем, у программиста на «Векторе» почти не было проблем с выводом спрайтов на сложном фоне (впрочем, большинство программистов-любителей всё равно предпочитали использовать привычный одноцветный чёрный фон
Кстати, если уж пошла речь об аппаратном наложении – у таких ПК обычно есть также возможность использования и других «хитростей»: имитации нескольких кадровых буферов (например, по одному монохромному буферу на одну плоскость экрана), аппаратного наложения нескольких планов (аналогично наложению спрайтов на фон – объекты на «ближних» планах могут перекрывать более «дальние» в том числе с «полупрозрачностью»), аппаратное маскирование части экрана (например, на половине выводится изображение, а вторая половина используется для хранения программ или данных) и просто управление объемом видеопамяти (часть плоскостей видеопамяти можно не использовать для вывода на экран, а хранить там данные).
И ещё замечание насчет возможности снижения вертикального разрешения – это не так уж бессмысленно, особенно если не хватает скорости или чего-то ещё. По крайней мере, у 8-битных Атари такой приём использовался часто (в некоторых играх было разрешение, по-моему, порядка 96 линий!, а уж 128 линий – это у них запросто, причем и горизонтальное разрешение было соответствующее – тоже от 128 точек). Не могу сказать, что такое низкое разрешение мне нравится (выглядит, по большому счёту, оно ужасно), но игры-то делали и продавали, и вообще в 80-х компьютеры Атари считались у нас очень крутыми игровыми ПК. У Атари, кстати, проблема в том, что при всей продвинутости их видеосистемы (всё таки специальный «видеопроцессор» с довольно гибкими настройками) многоцветное изображение можно было получить только при весьма низком разрешении, вот и делали такие «пикселизованные» игры. А в принципе возможность дублирования строк (и не только подряд, но и в разных частях экрана, и неоднократно) в сочетании с возможностью выбора горизонтального разрешения для каждой строки и аппаратными скроллингами, конечно, даёт потрясающие возможности для всяких видеоэффектов типа повтора групп строк на экране (например, аппаратного заполнения экрана какой-то повторяющейся «полосой», причём сдвинутой в разных фазах), мгновенного масштабирования, воспроизведения одной и той же картинки одновременно в разном масштабе и т.д. А еще можно же задействовать и цветовые эффекты с палитрами.
Прошу прощения за такую длинную «лекцию», но ваше замечание об отставании скорости графики на УКНЦ от БК из-за наличия в УКНЦ трёхплановой структуры видеопамяти меня, конечно, задело.
Спасибо за ссылку на статью о школьной информатике – конечно, я уже давно с ней знаком, но статья, безусловно, чрезвычайно интересная. Жаль только, что никаких цен там нет – а было бы интересно узнать цены не только на УКНЦ, но и, например, на «Корвет» (о его стоимости у меня вообще нет никакой информации – если сравнивать по числу микросхем, он вполне мог стоить и порядка 1000 рублей, как ПК8002 или наши ИБМ-совместимые, но в статье написано, что в 1987 году стоимость Корвета была в 2,6 раза больше УКНЦ – это что же, получается 1600х2,6=4160 рублей??? Как-то очень странно, если, конечно, речь идёт о «голом» Корвете – без дисководов и монитора).
Последний раз редактировалось vladtru; 06.10.2015 в 09:05.
Цена блока КНГМД БК0011М на заводе Экситон в начале 1991 г. была в районе 67 руб ( по др. данным - 76 руб, но точных данных нет. ). Блоки свободно продавались через бухгалтерию всем желающим, которые подносили "конверты с секретным содержимым " в отдел сбыта ( т.е. примерно +50% от цены блока в партии 10 шт. получалось ). Для тех, кого осциллоскоп и гриф "ДСП" не пугал, был еще более интесный путь ( которым я и пользовался в 1991-1992 г. ) - поездки на Ангстрем и покупки за ( почти ) бесценок КР1801ВП1-128 и КР1801РЕ2-326 ( 6-10 руб по ценам 1991 г. ) .А вот 1801РР1 стоили на А. весьма прилично. Их приходилось покупать на Тушинке, по цене около поллитры за 1 шт. - тогда была колоссальная инфляция, и стоимость бутылки самая наглядная. Голодающие несуны в середине 1992 г. продавали РР1 прямо в заводских запечатанных коробках, что бы случайно не "прошить" драгоценности статикой. Коррупции и хамства на А. небыло замечено - Москва это все-таки город приличный...
А платочки УПМ 7.102.122 ( контроллер КНГМД БК0011М ) можно было заказать в цеху Экситона по частному договору - в районе 5 руб за 1 шт. в партии 100 шт. ( 1991 г. ). Причем цена не изменилась и в 1992 г. - т.к. в бухгалтерии сидели клуши, знавшие о наличии и стоимости "вечнозеленого" только с экрана ТВ, отпускные внутризаводские цены были микроскопические до самого закрытия массового производства БКшек - конца 1993 г.
Я здесь ( на форуме ) писал не так давно, что в декабре 1993 г. Экситон распродавал БК0010-01 полностью годные в больших коробках по 12 шт. немного дешевле, чем можно было сдать эти компы на металл ( только считая КМ5, без учета всего остального ). БК0011М стоили в несколько раз дороже, подороже УКНЦ, и их выпускали немного, и с продажами их были очень серьезные проблемы - скорее бюрократического характера, чем экономического.
*
Кстати, самая дорогая деталь ( узел ) в компах 1991 г. была ИС ДОЗУ - КР565РУ5 стоили очень дорого, едва ли не дороже КР1801ВМ1 - в районе 9 руб, а РУ7 - вообще за 30 руб, причем по особой записи на А. ( что делалось в Минске в те годы - я не в курсах ).
Напомню, голая ДВК-2 стоила больше 15.000 руб в 1990 г, а в 1991 г. их вообще небыло в прайсах - только ДВК3, да еще и подороже.
Секция 5311 на А. с хранения в конце 1991 г. стоила в районе 980 руб - что вызывало смех грамотных товарищей, т.к. несуны продавали на Тушинке их по 50...200 руб ( лето 1991 г. ) в запечатанных коробках. 5305 б/у продавались от 30 до 100 руб, но ГРАМОТНЫЕ спецы по ЭВМ ими брезговали - там были проблемы с позиционированием на треки.
*
Кстати, контроллер КНГМД именно для БК0010 ( моего производства ) я увидел в августе 1991 в продаже на Тушинке, по цене в районе 500 руб. Мой хозяин их продавал в П-Посаде по 300 руб или немного дешевле ( 275 в партии от 2 шт. ??? ).
*
Тут в некотрых темах пишут о восстановлении дисковода 6022 - это ДЕРЬМО невозможно восстановить, оно было изначально гиганским позором МЭП. Там были ошибки механики при позиционировании головок, на экземплярах прямо с завода-изготовителя - лично проверял более 10 шт, и советую этот кошмар коммунизма сдавать поскорее кавказцам на металл, или выкидывать.
( Имею опыт борьбы с 6022 более 5 лет, результат - все повыкинул, даже зелень побрезгивал посрезать ( с первых экз. ) ).
*
Кстати, в конце 1992 г. 1 ваучер можно было сменять на Тушинке на секцию 5313 - по сути, ширпотреб от 5311, без электромагнита, с хранения.
Блог : http://collectingrd.kxk.ru/ . В ЛС прошу не писать, все сообщения [email protected]
offtop
меня греет, что интерес к Зеленоградским компьютерам и процессорам
не угасает, а местами споры жаркие кипят. Это приятно. Это хорошо.
[свернуть]
vladtru, так и не понял о каких тестах речь и откуда всплыл и причём тут ВМ3 ? В своё время прогнали на пяти (или 4 ? в совокупности) разных платах скоростные тесты по запросу Patrona, смотрите соотв. тему. там вся статистика должно быть жива ещё )
---------- Post added at 01:10 ---------- Previous post was at 00:56 ----------
vladtru, по поводу использования УК-НЦ без дисководов - был ещё вариант
ПЗУ с БЕЙСИКОМ - но вот таких картириджей я в свободной продаже в то время не встречал, их и сейчас не слишком много, так же как и родных, заводских КМД УК -в разы меньше чем самих машинок. И ещё возможность работы с принтером
на уровне "твёрдой копии экрана" без всяких ОС вообще. Магнитофон и УК-НЦ - это фикция по сути, ерунда, хотя список загружаемых таким образом программ
лучше известен Арсению, у него на сайте есть и
С удовольствием приму в дар или поменяюсь на что-нибудь, если у кого то есть "ненужный" картридж с БЕЙСИКОМ для УК-НЦ.
Вы здесь предполагаете, что скорость реальной УКНЦ это константа. Но насколько я понимаю, были более быстрые и более медленные экземпляры машины, и разброс мог быть в десятки процентов. Но даже если привязывать скорость к реальному экземпляру, то проблема в том, что длительность выполнения команды не выражается целым числом тактов, как ни парадоксально это звучит. Это происходит из-за задержек на шине, которые не постоянны. В итоге тест может дать что команда выполняется в среднем за 2,333 такта, но я же не могу такую задержку забить в эмуляторе процессора -- приходится округлять до 2. Задержки вносятся другими устройствами на шине, это в частности схема формирования видео, которая приоритетна по доступу к памяти и постоянно читает память. Поэтому для более точного тактирования нужна более глубокая эмуляция.
---------- Post added at 09:41 ---------- Previous post was at 09:29 ----------
Lode Runner на БК: https://github.com/nzeemin/uknc-lode...loderunner.lst
Порт на УКНЦ: https://github.com/nzeemin/uknc-lode...aster/MAIN.MAC
В порте на УКНЦ реализована работа с 4-цветными спрайтами -- т.е. совпадает с оригиналом, выставлен режим экрана 320x288.
На БК:
На УКНЦ:Код:; Приступаем к рисованию спрайта; R1 = адрес спрайта в 10 слов -- 8x10 цветных пикселей 005322 MOV #000012, R2 ; Повторить для 10. строк 005326 MOV (R1)+, (R3) ; записываем 8 цветных пикселей в растр 005330 ADD #000100, R3 ; плюс 64. -- переход к следующей строке растра 005334 SOB R2, 005326 ; продолжаем цикл по строкам
Как видите, вместо одной команде в этом цикле выполняются две. Такты я не считал, но очевидно, будет несколько дольше. Для 8-ми цветных спрайтов нужно уже использовать ПП, поскольку ЦП не может работать с 3-м планом памяти.Код:Z05322: MOV #000012, R2 ; Повторить для 10. строк Z05326: MOV R3, @#176640 MOV (R1)+, @#176642 ; записываем 8 цветных пикселей в растр ADD #80., R3 ; плюс 80. -- переход к следующей строке растра SOB R2, Z05326 ; продолжаем цикл по строкам
---------- Post added at 09:55 ---------- Previous post was at 09:41 ----------
В условиях, когда техника была в дефиците и в магазине просто так её было не купить, абсолютные цены не так уж и интересны.
Высокая стоимость Корвета объясняется низкой степенью интеграции. У разработчиков УКНЦ была возможность собрать бОльшую часть схемы в матричные К1801ВП1, Корвет же делало другое министертсво, такой возможности не было в принципе.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
