Переход из PM под ring3 в Real mode

Зачем вам DPMI в Windows?!
Зачем вам STI/CLI в Windows?!
Напишите что вы вообще хотите сделать и мы вас убедим, что для этого есть WinAPI, а не такие извращенские способы.

Поймите, в WinAPI есть всё, что давал ДОС. И даже намного больше.
Надо работать с аппаратурой - пишите драйвер ring0, во всех остальных случаях всё, что вы хотите сделать абсолютно не нужно.

 

KIV
Все еще пытаюсь запрограммировать DMA, а DPMI нужен для выделения памяти под буфер DMA в первом мегабайте RAM, конечно есть функция AllocateBuffer, специально для этого предназначенная, но под Delphi ее не очень то используешь, потому что для этого требуется файл Portcls.h из DDK и никаких DLL для ее вызова не предусмотрено.
CLI и STI также нужны при программировании DMA, а если учесть что я его собираюсь использовать в простеньком плеере wav файлов, то писать драйвер ой как не хочется, потому что никогда этим не занимался.

 

SOA
Либо вы олдскул, раз вам знаком функционал первых версий винды(не NT), либо вы начитались не той литературы не имея никакого представления. В NT DPMI сервисов нет. DMA вам не нужен. Установите нормальную среду и изучайте ось.

 

SOA

Можно, можно выполнить кодец в V86 (эмуляция "DOS") - например тупо сделать чистый MS-DOS модуль и запустить его как процесс. DPMI тоже будет работать, возможно - в 98-ой же работало.

Только это будет все одно эмуляция. Все прерывания и обращения к портам будут идти через менеджер и я че-то сомневаюсь что вам дадут DMA маньячить.

Так что вам выше все верно сказали - сначала нужно посмотреть что можно сделать на WinApi или через сервисы драйверов (DeviceIoControl). Если вы хотите wav играть - нужно юзать апи, если нужно сделать проигрываель для DOS - при чем тут дельфи?

 

Хотя да, можно поставить 9x и решать её проблемы. Для ТС это оптимальный вариант.

 

Clerk
Я скорее второй тип
Литературу читал ту что в первом сообщении указал(не полностью правда) + Internet.

Нет нужен (хотябы потому что интересно)

PSR1257

Про DeviceIOControl мне в другом месте много более опытные чем я люди, уже говорили, но я просто не представляю где брать коды функций для DMA. На MSDN смотрел, но не нашел, конечно может быть плохо смотрел.

Про API знаю, просто хочется свое своими руками, ну и в перспективе освоить DMA передачу данных между буферами в памяти. В общем просто интересно.

 

SOA
Вам нужен DMA, собрались первый метр памяти копировать, для чего если можно тупо rep movsd ?
ISA DMA вы не закодите, личный опыт. Зачем оно нужно ?

Вобще топик ниочём.)

 

Clerk
Почему первый, там же есть режим память память, я так понимаю можно в расширенной памяти копошиться.
Вопрос зачем, просто интересно, хобби.

 

SOA
Есть ^

 

Ну так я ж уже писал что тему можно закрыть.

 

SOA

Во-первых, стандартный контроллер ДМА (времён 8086/186/286) не выходил за пределы 16 мегабайт, да и то с плясками (поскольку собственно микросхема 8257 была 16-разрядной). Ну а во-вторых, режим "память-память" уже сто лет как упразднён, насколько помню. Ну и по-любому идея дурацкая. Если программа делается под некоторой ОС, она и должна работать по правилам этой ОС, а не вопреки им.

 

Если интересна работа с аппапатурой, то ставьте DOS и наслаждайтесь. В винде поиграться с аппаратурой так просто не удастся. Сама архитектура многозадачной ОС стремится скрыть особенности аппаратуры от приложений.

 

> Сама архитектура многозадачной ОС
Сама архитектура любой ОС

 

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

 

SII

не знал.

Не согласен, потому что если мы говорим о низкоуровневом программировании, а не об API программировании, то идея нисколько не дурацкая, да и потом программы бывают разные одни ориентированные на работу, под конкретной ОС, а другие ориентированные на работу с железом, независимо от ОС.

KIV

Знаю, видел.

 

SOA

А не подскажете-ка хоть один примерчик? Ну хоть одну программку, которая будет работать с железом независимо от того, под какой ОС её запустить.

P.S. Это я к тому, что правила для приложений, работающих с железом, (драйверов) у ОС гораздо более строгие, чем для обычных прикладных. И даже если Вы где-то и не играете по её правилам, то как минимум знать и учитывать их Вам всё равно придётся.

 

l_inc
А не подскажете-ка хоть один примерчик? Ну хоть одну программку, которая будет работать с железом независимо от того, под какой ОС её запустить.

Ну например программа, осуществляющая КИХ-фильтрацию сигналов на процессоре DSP TMS320C4x. Данная программа от оси на Вашем хосте никак не зависит. Так как INTEL даже инструкции этого DSP'шника не поддерживает, эмулятор, не важно в какой ОС он запущен, просто отсылает их подключенному к компу DSP'шнику на исполнение, показывает состояние его регистров.
Эту прогу саму - рассматривают как ось сигнальника.

 

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

Потому что там я так понимаю, как и в DMA все простейшие действия зависят от значений записанных в тот или иной порт устройства. Откуда я делаю вывод что исходники процедур, программирующих то или иное действие устройства на tasm для windows и fasm для nix будут практически одинаковыми, с некоторыми поправками на синтаксис языка, и могут быть включены для первого случая в программу написанную на Delphi, а во втором случае в программу написанную на Free pascal.

 

Nafanya
Неужели эта лаба всё ещё включена в универскую программу? (для друга как-то ких-фильтр писал под что-то похожее)
Лан... Это была вроде как шутка, а по сути это не будет работой с железом. Это будет работа с эмулятором.

SOA
Драйвера видеокарт? Вы, наверное, шутите? Ещё раз: у каждой ОС свои правила для работы драйверов. Драйвер должен предоставлять интерфейсы ОС и вызывать интерфейсы ОС. У него строго определённая правилами оси структура и даже последовательность выполняемых им действий. А то, что у какого-то драйвера будет несколько идентичных для разных осей процедур (ну процентов 50 кода, скажем), которые специфичны для устройства, так это кагбэ ни разу не "независимость от ОС".

Кстати, для справки: fasm и free pascal можно было брать для обеих осей. А такую древность, как tasm нет смысла ни под windows, ни под unix использовать.

 

SOA
Тебе прямая дорога работать с эмулятором. Настоящая старая школа тебя интересует.

Железо меняется. ОС тоже меняется. Лично я каждое десятилетия считаю новой компьютерной эпохой.

1980-1990 Если раньше был дос с доступом к 1 мб. И костылями для 16мб. То и аппаратура была соответствующей. Потом появился новый процессор с защищенным режимом появилась новая ОС win 3.11.
Сменилась шина и постепенна поменялась вся аппаратура.

1990-2000
Появления win 98.
DMA 8257 исчез как класс и поддерживался только для совместимости.
Контроллер HDD стал программироваться по другому, но совместимость сохранялась.
Стандарт звуковой карты SoundBlaster продержался чуть дольше до 98 года. Ему на смену пришёл AC97 между прочим в некоторых реализациях совместимость утеряна и эммулируется программно в виндоусе.
Так что не светит тебе поработать со звуком.

Новый век 2000-2010 год. Настала пора HDD отказаться от совместимости, но пока еще совместимость какая никакая есть. Но AHCI не дает поддержки покоя. Windows XP. Эра 64битных процессоров.
Ближе к концу десятилетия звуковая система по менялась интегрировалась с видео картой. Революции не случилось, но именно в этих годах Intel хотелось отказаться от совместимости. Планировали даже переписать BIOS.

2010-2020
Эра виртуализации? Новая архитектура? Думается процессор перекачует в биос, а ОС на видео карту?