LINUX.ORG.RU

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

 , , , z386,

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

6

7

Энтузиасты смогли успешно извлечь и дизассемблировать микрокод процессора Intel 80386, который из-за отсутствия документации считался «чёрным ящиком». Бинарный образ микрокода был воссоздан с привлечением AI по фотографиям кристалла в высоком разрешении, а логика работы разобрана через трассировку соединений на кристалле. Постепенно были определены структура микрокоманд (μ-ops), поля, порядок исполнения и маркеры конца инструкций. Наработки проекта опубликованы на GitHub как общественное достояние.

Выявлено, что в CPU 80386 каждая инструкция полностью исполняется через микрокод, в то время как в 8086 и современных процессорах часть инструкций обрабатывается напрямую. Кроме того, в отличие от процессоров 8086, в 80386 микрокод не реализует алгоритмы напрямую, а в основном настраивает аппаратные ускорители (умножитель, делитель, быстрый сдвиг, PTU (Protection Test Unit)).

В ходе исследования также была обнаружена возможная проблема с безопасностью при обработке битовой карты прав доступа к вводу/выводу (IO permission bitmap): при 4-байтовом обращении к портам проверялись биты прав доступа только для первых 3 байтов, а доступ к 4-му байту не проверялся, что теоретически допускало обращение к аппаратным регистрам, доступ к которым должен был быть запрещён.

На основе опубликованного микрокода разработан открытый CPU z386, реализованный на языке SystemVerilog и работающий с использованием FPGA. Вместо реализации каждой инструкции в форме отдельного RTL (wikipedia.org) (Register-transfer level) в z386 реализованы аппаратные структуры, которыми управляет оригинальный микрокод. Производительность подготовленной реализации соответствует быстрому 386 ПК (~70MHz). Под управлением z386 удалось успешно запустить DOS 6/7, DOS/4GW, DOS/32A и игры, такие как Doom и Cannon Fodder.

>>> Подробности на opennet

★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Смысл - в сохранении технических компетенций и отсутствии жесткой зависимости от зарубежных поставщиков. Но тогда этого не понимали даже на уровне руководителей государства. Известна историческая фраза Гайдара в диалоге с министром станкостроения Паничевым, когда он сказал «Да кому нужны ваши станки?! Понадобятся - мы все за рубежом купим». Вот теперь нам это аукается :(

Какие сохранения компетенций в 1992 году при условии нелицензионного нелегального послойного копирования, часто без понимания что тут что? Да ещё и неконкуретного в любом разрезе. И в то время почти все поставщики стали зарубежными. Таможенный контроль и сборы с той же РФ отменили лишь в середине 1995.

OSBuster ★★
()
Ответ на: комментарий от lenin386

во-первых, я это не только читал, я писал эмулятор этого, и он работает

Ну так ведь «То, что ты несешь, с таким самоуверенным видом - никак не может быть, что ты с этим хоть как-то работал» © :)

Нет в BГ93 никакого буфера, если не считать 1-байтого регистра, и обратной связи при чтении данных нет. И в даташите нет таких слов, и быть не может. Потому что нет. Буфера.

И что?? Я ни слова не сказал о буфере вообще, это твоя фантазия, неуважаемый...

включая меня

Так а «бремя доказательства лежит на утверждающем?»??.. Или это работает только в одну сторону? ;))

Так кто и где тебе сказал, что прочитал HD Floppy на Синклере?

Твои фантазии комментировать не интересно, сам придумывай и сам и отвечай, и дальше...

И, раз уж у нас тут «вечер вопросов и ответов» «нарисовался», скажи, «знаток», почему не все дисководы были пригодны для работы с «Спектрумами»?.. Узнаешь - сам себе и ответишь... может быть... ;))

Пруф будет, или опять привидилось?

«Пруф» чего? Того, что ты тут активно фантазируешь, приписывая свои фантазии мне? Так перечитай ещё раз комментарии... А пока что бывай...

P.S. И про IDE советую почитать, чтобы не нести больше такой чуши, как ты здесь пишешь, типа «FPGA минимум из 2000-х»...

Somebody ★★★★
()
Ответ на: комментарий от lenin386

Теледиск копирует симуляцию плохих секторов.

Я ж сказал не «плохих», а нестабильных. Скопировать можно только то, что прочитается, а если читается то одно, то другое, сформировать такое дисководом нельзя.

GAMer ★★★★★
()
Ответ на: комментарий от OSBuster

нелицензионного нелегального послойного копирования, часто без понимания что тут что?

Разбираться «что тут что» приходилось. Я знаю как минимум о защите Z80 и VAX. Разбирались и исправляли.

GAMer ★★★★★
()
Ответ на: комментарий от Somebody

И, раз уж у нас тут «вечер вопросов и ответов» «нарисовался», скажи, «знаток», почему не все дисководы были пригодны для работы с «Спектрумами»?

Чойта они не пригодны? Даже такой простой доработки сделать не смог, а уже о турбировании ВГ рассуждаешь. 2-я нога, density select, через сопротивление на +5в, переключает его в режим DD, и всё прекрасно работает. Вообще-то, этой ногой должен управлять контроллер, но нет у ВГ такого.

«Пруф» чего ?

Того, что кто-то, как ты утверждаешь, читал HD floppy на Синклере... И того, что это возможно.

Или это работает только в одну сторону? ;))

Это работает в сторону утверждающего. Ты _утверждаешь, что прочитать HD floppy на Синклере - можно. И кто-то это делал. Вот, и твое дело это доказывать. Пруф приведи. Мне же, для опровержения, ничего доказывать не нужно. Потому что «чайник Рассела». Тем не менее, я могу привести выкладки, что 500 kb/s, стандартный Синклер не осилит. И прекрасно помню, что приводил уже их тут. Впечатлило это кого-то? Нет, конечно. Тебе почему-то не понятно даже то, что турбирование - не всегда вообще работает. Ты даже не знаешь, что собственно ВГ сейчас никто не использует, они ломучие. А то, что испольщуется, MB8877a и аналог от Mitsubishi - не турбируется.

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)
Ответ на: комментарий от Somebody

но там нужен турбированный вг93
самое занятное, что z80 3.5МГц кое-как успевает прочитать, а вот 8088 5МГц сам без дма уже не справится

madcore ★★★★★
()
Ответ на: комментарий от lenin386

Чойта они не пригодны?

Тойта. RTFM, «експЁрд»... :)

Даже такой простой доработки сделать не смог

Клевета.

а уже о турбировании ВГ рассуждаешь.

Ты лжёшь.

В общем, «експЁрд» не угадал ты, не поэтому не все модели «флопповодов» годились для работы со «Спектрумом»...

Somebody ★★★★
()
Ответ на: комментарий от GAMer

Товарищ, ты крайне опасно путаешь чтение сектора и чтение дорожки. Сектор может не прочитаться. Не совпало CRC, из-за каких-то таймингов он не найден... А дорожка всегда читается. Это просто магнитный носитель. Просто байты от маркера до маркера. Как может не прочитаться дорожка?

lenin386 ★★★★★
()
Ответ на: комментарий от madcore

Не успевает z80 без турбирования. 7-8 Mhz надо, это самый предел вообще быстродействия, выше про 14 я погорячился, не работает Синклер на 14.

lenin386 ★★★★★
()
Ответ на: комментарий от madcore

А «там» это где??...

самое занятное, что z80 3.5МГц кое-как успевает прочитать

То есть, таки успевает? ;) Ну, хоть кто-то это знает... :)

а вот 8088 5МГц сам без дма уже не справится

Это как раз таки легко объяснить: разное количество машинных тактов на выполнение одной команды этими процессорами и разная «скорость» выполнения операций ввода-вывода ими же...

Ну и схемотехника, думаю, «играла рояль»... Предполагаю, т.к. с 8086 и 8088 не работал...

Somebody ★★★★
()
Ответ на: комментарий от Somebody

Это как раз таки легко объяснить: разное количество машинных тактов на выполнение одной команды этими процессорами и разная «скорость» выполнения операций ввода-вывода ими же...

Угу. И z80 тут в такой жёппе... Со своими 16-23 тактами на операцию.

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Ну это вопрос преодоления фильтра, в идеале качественный код по практике - компиляется значит автор прав :(

qulinxao3 ★☆
()
Ответ на: комментарий от lenin386

Несмотря на то, что шина позволяла, я вроде как читал интервью Билла Гейтса (сейчас уже не припомню детали). Он говорил, что DMA в драйверах Floppy не использовали, потому что было огромное количество дешёвых китайских контроллеров, в которых DMA реализовано не было. Из-за совместимости со всем этим, решено было просто на DMA забить. Отсюда, кстати, этот анекдот-легенда про многозадачность. «Сейчас, только дискету доформатирую». Флоппи драйвер получил DMA чуть-ли не в Windows 2000 только, до этого только PIO было.

было бы интересно взглянуть на это интервью, но мне кажется, что у тебя в голове всё смешалось
дисководы на пц использовали дма с самого первого дня, иначе просто не могли, «дешёвые киайские контроллеры» попросту не работали бы
в pio работали старые иде-винты(у меня даже такой был) и вин95 по дефолту на кривых чипсетах

madcore ★★★★★
()
Ответ на: комментарий от madcore

там где ты собрался читать хд-дискеты, очевидно

Я ничего не собирался читать, кроме как старые дискеты сына, записанные на «персоналке», на персоналке же. Но для этого у меня нет флопповода 5.25"...

А на «Спектруме» спокойно читались и писались дискеты в его собственном формате, «сильно другом». Это работало 100%, а деталей технической реализации я, разумеется, не помню - больше четверти века уже прошло, лет с 25-30, наверное, как я этим («Спектрумами») не «балуюсь»...

Где-то должна ещё валяться плата ( или две, не помню :)) ) «Ленинграда-2» с подключенной к ней платой контроллера дисковода как раз на КР1818ВГ3, но... «Это было так давно», что и не помню, где оно... Да и не нужно мне это. :)

Somebody ★★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от monk

Что такое «операция» в ваших терминах?

Ассемблерная команда с конкретными аргументами

Это in-order, но с дополнительными вариантами команд

Я всё понял и думаю, что полностью разобрался. Если бы вы с самого начала не предполагали, что случайный собеседник на ЛОРе знает детали реализации выборки команд процессора Эльбрус, мы бы давным давно разобрались. Вам просто нужно было сказать что-то вроде

В Эльбрус существенно упрощен блок выборки команд. Болшинство задач по декодированию, планированию, и назначению инструкций вынесено на уровень компиляции. Это упрощает блоки микроархитектуры между входом инструкции и входами выполняемых конвейеров. Преимущества такого подхода понятны. Фактически составная операция элементарно декодируется в 6 инструкций, которые детерминированно распределяются по исполняемым конвейерам. Это означает, что одна ассеблерная операция фактически содержит до 6 опкодов, а значит по ассемблеру можно определять производительность и загрузку каждого конвейера. Исполнение in-order, поэтому правила согласования инструкций проверяются на уровне ассемблера. 

Здесь всё верно? Этот параграф однозначно соединяет ассемблерную команду - она же «операция», инструкцию - она же составляющая операцию, и опкод - который обычно 1-1 соответствие каждой операции modulo регистры и операнды.

Если всё так, то, конечно, это просто праздник для программиста. Ясен пень, если нужно выжать производительность из такого процессора, то программировать на С это всё будет безумием. Вы получите ну 0.2 инструкции за такт, ну может 0.5. Чтобы получить хотя бы 3, надо по-любому программировать на ассемблере. То, что конверсия в опкоды однозначная, путь до конвейера детерминирован, и правила распределения по конвейерам известны превращает задачу в поиск остовного графа на графе зависимостей инструкций. Тогда становится понятны все ваши замечания по поводу ассемблера.

Выбор таких решений вполне понятен. Он диктуется реалиями разработчиков микроархитектуры, за что им большое уважение! Полагаю, недостатки такого подхода им тоже известны, но преимущества перевешивают. Надеюсь вы, как программист этого изделия имеете много фана.

VIT ★★
()
Ответ на: комментарий от madcore

тогда я потерял контекст обсуждения

Я не брал!.. ;)))

Somebody ★★★★
()
Ответ на: комментарий от Somebody

Те, что 4 такта, очень мало полезны в таком коде... Любая работа памятью - это 16+ тактов. Кроме, стека. Там, 8-9. Но это считалось суппер быстро.

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от madcore

1) Это, конечно, гениальный код. Работать он конечно же не будет. 2) Тааак. А теперь, разделим 4000000/26 = 153 846. Ой. А 250 килобайт в секунду? Где взять? А 500?

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

1) будет работать на доработке с /wait, иначе нужно турбировать проц
2) как у тебя биты превратились в байты

madcore ★★★★★
()
Ответ на: комментарий от VIT

Здесь всё верно?

Почти. 6 опкодов для АЛУ и ещё несколько для других подсистем. Остальное всё верно.

Ясен пень, если нужно выжать производительность из такого процессора, то программировать на С это всё будет безумием. Вы получите ну 0.2 инструкции за такт, ну может 0.5. Чтобы получить хотя бы 3, надо по-любому программировать на ассемблере.

Нет конечно. Достаточно иметь нормальный компилятор. lcc пакует лучше среднего программиста.

То, что конверсия в опкоды однозначная, путь до конвейера детерминирован, и правила распределения по конвейерам известны превращает задачу в поиск остовного графа на графе зависимостей инструкций.

Да. И её лучше поручить компилятору, а не пытаться решить в уме.

Вот пример

#define UL unsigned long

void adds(UL as, UL am, UL bs, UL bm, UL *ress, UL *resm, UL s)
{
   if (as == bs) {
      *resm = am + bm;
      *ress = as;
   }
   else if (am >= bm) {
      *ress = as;
      if (!s)
          (*resm)++;
   }
   else {
      *ress = bs;
      if (!s)
          (*resm)--;
   }
}

lcc 1.26 компилирует в 10 тактов

        {
          setwd wsz = 0x4, nfx = 0x1, dbl = 0x0
          return        %ctpr3
        }
        {
          cmpbdb,0,sm   %r1, %r3, %pred0
          cmpedb,1      %r0, %r2, %pred1
        }
        {
          nop 1
          pass  %pred1, @p0
          pass  %pred0, @p1
          landp ~@p0, ~@p1, @p4
          pass  @p4, %pred2
          landp ~@p0, @p1, @p5
          pass  @p5, %pred0
        }
        {
          cmpedb,0,sm   %r6, 0x0, %pred3
          std,2 %r4, 0x0, %r0 ? %pred2
          std,5 %r4, 0x0, %r2 ? %pred0
        }
        {
          ldd,0,sm      %r5, 0x0, %g16
          addd,1,sm     %r1, %r3, %g18
          ldd,2,sm      %r5, 0x0, %g17
          pass  %pred0, @p0
          pass  %pred3, @p1
          landp @p0, @p1, @p4
          pass  @p4, %pred0
          pass  %pred2, @p2
          landp @p2, @p1, @p5
          pass  @p5, %pred2
        }
        {
          nop 1
          std,2 %r5, 0x0, %g18 ? %pred1
          std,5 %r4, 0x0, %r0 ? %pred1
        }
        {
          addd,0,sm     %g16, 0x1, %g16
          subd,1,sm     %g17, 0x1, %g17
        }
        {
          ct    %ctpr3
          std,2 %r5, 0x0, %g16 ? %pred2
          std,5 %r5, 0x0, %g17 ? %pred0
        }
monk ★★★★★
()
Ответ на: комментарий от madcore

Z80 с WAIT - это просто пропуск тактов, он не умеет считать в ожидании памяти. Сделать можно, но производительность будет аналогично 8-10 мегагерц, максимум. Да, биты с байтами я сгоряча перепутал, но и твой код не рабочий. Что-то мне совсем не хотелось это писать, будет что-то типа того:

Алгоритм такой : 1) Анализируется флаг готовности 2) Получается байт 3) Записывается байт 4) Инкрементируются счётчики. 5) цикл.

LD HL, XXXX;- TARGET

LOOP:
IN a, (0xff) ;; 11 тактов
; Эти 4 строки лажа скорее всего в номерах битов и кондициях проверки, но мне недосуг это вспоминать
BIT 6, a ;; 8 тактов 
JR NZ LOOP ;; 12 тактов
BIT 7, a ;; 8 тактов
JR Z, BREA ;; 12 тактов
in a, (0x7f) ;; 11 тактов
LD (HL), a ;; 8 тактов
INC HL;; 6 тактов
JR LOOP ;; 12 тактов
BREA:

88 тактов. 318 176 бит/с. Ну, так и есть. 250 kbs - пролазит, 500 - нет.

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 4)
Ответ на: комментарий от lenin386

это почти оригинал из tr-dos, вот отыскал

LOOP_DRQ:
        IN A, (#FF)     ; Читаем порт системного контроля Beta Disk
        ADD A, A        ; Сдвиг бита 7 (INTRQ) во флаг переноса C
        JR C, DISK_END  ; Если INTRQ=1, ВГ93 завершила работу раньше времени
        JP P, LOOP_DRQ  ; Если бит 6 (DRQ) равен 0, продолжаем ждать байт

        ; Байт готов в регистре данных ВГ93!
        INI             ; Команда Z80: чтение из порта C (#7F) в память (HL), 
                        ; декремент B, инкремент HL.
        
        JP NZ, LOOP_DRQ ; Если B != 0 (не все 256 байт прочитаны), на следующий байт


цикл ожидания можно опустить, если схема с вг93 доработана на К555ТМ2 выставлением wait(так, например, было на турбированных клонах, хоть использовалось и не для этого)
ес-но штатными средствами такой диск не прочитать, но схемы с такими доработками были
с практической стороны не очень полезные, конечно

madcore ★★★★★
()
Ответ на: комментарий от madcore

Да, покрасивее. 65 тактов/байт. Но все равно 500 kbit/s на 3.56 Mhz не вырисовывается. Вообще, это многократно обсуждалось. Нет, без разгона z80, не работает. Ещё играет роль то, что вот так просто работать тоже не будет. Регистры ВГ93 доступны только из ПЗУ beta disk. Поэтому, на деле, немного не так будет, но это уже я не буду развивать.

lenin386 ★★★★★
()
Последнее исправление: lenin386 (всего исправлений: 2)
Ответ на: комментарий от VIT

не обязательно на асме

но да - для hll ПОТРЕБУЕТСЯ специфические прагмы али специфичиские команды которые будут байтить возможности vliw цели т.е по факту будет не строчный асм а какбе структурный

qulinxao3 ★☆
()
Ответ на: комментарий от lenin386

Ты путаешь ISA DMA и PCI busmaster DMA.

Флопики использовали именно ISA DMA. Он был еще в самых первых PC. DMA-контроллер работал на частоте 4.7МГц. Производительность CPU росла, а DMA-контроллер так так и остался на 4.7МГц. Поэтому практически никто кроме флопика его и не использовал.

Windows 98/2000 - это уже очевидно всякие PCI busmaster DMA (всякие DMA/UltraDMA 33/66).

bigbit ★★★★★
()
Ответ на: комментарий от qulinxao3

ну вроде как в нипоне до сих пор всякий антиквариат вполне читаем-писуем

Не настолько сильно оно мне нужно... Просто «хотелось бы, но раз нету, то и ладно...». :)

Сын ещё классе в 9-м, 10-м написал на Visual Basic «черепашку» - LOGO для уроков информатики в «родной» школе. Школа сказала, что получилось лучше, чем им «выдавали» «сверху»...

Вот и хотелось бы найти «исходники». Для этого надо «просмотреть» старые дискеты. Но это больше ностальгия, чем необходимость... Иначе бы давно уже решил эту «проблему»...

И потом, давно уже нет у меня «каналов» для заказа из Японии. В 90-е я активно оттуда «возил» всякую рухлядь электронную для «рукоблудства» всякого, а сейчас и «морских"знакомых не осталось. А через незнакомых выйдет слишком дорого для „хотелось бы“...

Somebody ★★★★
()
Ответ на: комментарий от saufesma

Там за три штуки 2999₽.

Я китайцам за сотню меньше плачу́, чем за «три штуки» «родных до слёз»...

А китайские «три штуки» стоят «в розницу» примерно 300 рублей. Уже распаянные на платах, да. :)

Дальше объяснять, или?.. ;))

Somebody ★★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от Somebody

Весь вопрос, где они используются. Если их нужна сотня, а устройство стоит 10 тысяч, то приходится выбирать китайское. Если же нужен один контроллер для устройства ценой в 200 тысяч, то разница между нашим и китайским на фоне общей стоимости теряется.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от lenin386

SVGA в принципе херовая идея, с защищённым режимом, вообще-то, не совместимая

Что ты несёшь?! SVGA это все VGA-совместимые видеокарты с поддержкой разрешений больше чем 640х480. Режим проца никак на их работу не влияет.

firkax ★★★★★
()
Ответ на: комментарий от drfaust

VESA v.2 тормозит дико

Чего там тормозит? VESA это переключатель режимов, ещё несколько вспомогательных функций и фреймбуфер. Если хочешь не фреймбуфер то это уже карты с ускорителями и совсем другая история.

firkax ★★★★★
()
Ответ на: комментарий от monk

Ну, эта «азбука» мне знакома. Именно потому и...

Somebody ★★★★
()
Ответ на: комментарий от firkax

SVGA это все VGA-совместимые видеокарты

это несвязанные вещи
а до появления vesa там вообще бардак был

Режим проца никак на их работу не влияет.

в некотором смысле влияет
для lfb нужно быть в защищённом режиме, либо в так наз. unreal
а в режимах банков без lfb многие видяхи дико тормозили

madcore ★★★★★
()
Ответ на: комментарий от firkax

Так тогда считалось, поэтому, и называли таким образом библиотеку. Сейчас под SVGA понимается VESA-совместимосить. Ядро Линукс не собирал? SVGA framebuffer console.

lenin386 ★★★★★
()
Ответ на: комментарий от lenin386

Нет, так называли видеокарты. А библиотека (одна из многих) называлась так потому что она была для работы с этими видеокартами.

Сейчас под SVGA понимается VESA-совместимосить

Не понимается и никогда не понималась. SVGA - это всё то (железо), что совместимо с VGA, но при этом дополнительно поддерживает разрешения 800x600 или выше. VESA - модуль биоса, который позволяет управлять SVGA-картой совместимым между разными картами способом (указанным в спецификации VESA). Ещё были реализации VESA в виде резидентных прог для доса (разумеется, они подходили только к конкрентым картам).

Сейчас ни первое ни второе не особо актуально: во-первых, видеокарт без поддержки 800х600 давно не производят, во вторых совместимость с VGA и наличие VESA BIOS сейчас интересно только с позиций запуска старых ОС, чем мало кто занимается. Я даже не уверен что современные видеокарты все под это подходят. Хотя, конечно, VESA очень хорошая идея и было бы печально если её дропнут.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от madcore

Что с чем не связано? Если карта поддерживает VGA и поддерживает 800x600 то она SVGA, вне зависимости от того, если ли в ней VESA BIOS или нет. Если VESA BIOS нет, то для работы в SVGA-режиме нужен будет кастомный драйвер или хотя бы знание кастомного его номера.

Для того, чтобы у карты был линейный фреймбуфер, от проца ничего не требуется. От проца что-то требуется чтобы суметь к этому фреймбуферу обратиться, но это не проблема видеокарты никаким боком. И никакого unreal режима не существует, это выдумки нубов. То что так называют - это обычный реальный режим 386+ процов, в котором в дескриптор FS или GS прописали длину сегмента больше 64к. Да, он отличается от реального режима 8088 (и если не прописывать большую длину - тоже будет отличаться), но это же другой проц.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Если карта поддерживает VGA и поддерживает 800x600 то она SVGA,

изначально SVGA в названии карты лишь витиевато намекает, что карта, вероятно, совместима с VGA и может что-то ещё, не более
например, 640*480*8 или 320*240*24 тоже ведь не vga-режимы
сакральные 800х600 начали ассоциировать с svga именно после появления vesa

Для того, чтобы у карты был линейный фреймбуфер, от проца ничего не требуется.

странно, а я ведь написал, что ему требуется 32-битный доступ к этому буферу

но это не проблема видеокарты никаким боком

ну как это никаким боком, она должна поддерживать vbe2.0

И никакого unreal режима не существует, это выдумки нубов.

дядя, именно этот термин повсеместно использовался тогда для обозначения этого
а мелкомягкие также придумали название big real mode
собственно, это изначально баг 386, который в итоге пришлось оформить как фичу

madcore ★★★★★
()
Ответ на: комментарий от madcore

При оценке видеокарт в первую очередь смотрели на разрешение, поэтому всякое 640x480x8 это конечно больше чем VGA, но критерий второстепенный. CGA - 200 строк, EGA - 350, VGA - 480, SVGA - > 480.

странно, а я ведь написал, что ему требуется 32-битный доступ к этому буферу

Процу требуется, но на видеокарту это не влияет.

ну как это никаким боком, она должна поддерживать vbe2.0

Да, видеокарта предоставила фреймбуфер на 0xD0000000 - свою спецификацию выполнила. Как проц будет к нему обращаться - уже не её дело.

дядя, именно этот термин повсеместно использовался тогда для обозначения этого

Я не отрицаю что этот «термин» где-то там использовался. Однако это не делает его более грамотным. Никакого отдельного режима не существует, это просто реальный режим. big real mode уже ближе к истине.

собственно, это изначально баг 386, который в итоге пришлось оформить как фичу

Очередные фантазии. Всё было изначально указано в спецификации. Утилитарный способ эксплуатировать логику работы проца для доступа ко всей памяти из реального режима в ней рассмотрен, разумеется, не был, но сама логика работы специфицирована корректно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

При оценке видеокарт в первую очередь смотрели на разрешение,

смотрели в меру своих способностей...
толку тебе от 800*600, если мониторы массово либо не умели, либо в 60Гц
а вот цветов насыпать больше 256, или скорости...

big real mode уже ближе к истине.

ты щас серьёзно?
можешь растолковать, чем unreal хуже big real, учитывая, что обоих терминов в документации интел не было

Всё было изначально указано в спецификации.

ткни пальцем в изначальную спецификацию, где указано, что при возврате из защищённого режима 386 должен забывать сбросить лимиты в кэше дескрипторов?
это официально узаконили, когда начали вовсю пользоваться, в том числе в himem.sys

madcore ★★★★★
()
Ответ на: комментарий от madcore

а вот цветов насыпать больше 256, или скорости...

К SVGA видеокарте прилагается SVGA-монитор, поддерживающий такую развёртку. И, кстати, для монитора уж точно важно только разрешения, цвета и так и так аналоговые.

можешь растолковать, чем unreal хуже big real, учитывая, что обоих терминов в документации интел не было

Тем, что big real mode = real mode с добавленным к нему бытовым прилагательным «big». Это не новый режим, а смысловое (не техническое) уточнение к старому. Unreal же это другое слово, которое к тому же антоним к real.

ткни пальцем в изначальную спецификацию, где указано, что при возврате из защищённого режима 386 должен забывать сбросить лимиты в кэше дескрипторов?

Что значит «забывать»? А может ещё про то, что EAX не сбрасывается, тоже надо явно указывать? Инструкция MOV CR0,EAX меняет ТОЛЬКО содержимое регистра CR0. Все остальные изменения - те, что применяются в реальном времени в зависимости от этого бита (в смысле что меняется поведение некоторых инструкций). Не сбрасывается даже декодированная в защищённом режиме очередь инструкций вперёд, из-за чего рекомедуется после переключения режиме делать JMP на следующую инструкцию, NEAR годится.

И это не «кеш дескрипторов» а теневые регистры, вполне полноценные, но недоступные для прямого обращения из ассемблера документированным способом. Недокументированным их можно было записывать и в 286 и в 386, без перехода в защищённый режим. Но в 286 лимитов больше 64к не было, понятное дело, а вот базовый адрес можно ставить за пределами 1МБ, чем и пользовался himem.sys.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.