Страниц: [1] 2
  Печать  
Автор Тема: вопрос про старый дос  (Прочитано 12223 раз)
vkorn
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« : Сентября 15, 2004, 11:57:04 am »

Конечно не совсем про QNX!!!

есть USB (1.1 - OHCI) в ДОС.

Биос выделяет кусок памяти для работы с хост контроллером. Базовый адрес - 0xfcfff000.
 
Так вот вопрос, как достучаться до такого адреса в реальном режиме дос.

Ответьте кто знает
Записан
bond
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #1 : Сентября 15, 2004, 12:36:18 pm »

pro perehod v lineinii regim adresacii
http://shop.piter.com/chapt.phtml?id=978594723487&refer=3090
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #2 : Сентября 15, 2004, 12:53:45 pm »

vkorn
адреса в реальном режиме дос

три варианта:

1) Не запускать ни himem, ни emm386, войти в protected mode, засетапить селекторы на 4G, выйти из protected mode (хотя из него выходят только ногами вперед ... в общем вернуться в полу-protected 16 bit mode ) теперь можно писать что-то вроде mov [0fcfff000h], eax в 16-битной программе все будет работать. Это указано в статье указанной Bond'ом.

Недостаткой в этом методе больше чем плюшек. Да и код какой-то здоровый в статье. Я уложился в свое время в 200 байт

2) Использовать TASM32 как ассемблер и генерить код для 32bit protected mode. Цеплять вручную DOS extender.

3) Использовать WatcomC и компилить на С/C++ под DOS4GW (потом DOS4GW заменить на любой пристойный extender).

Я склоняюсь к 3-ему методу
Записан

klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #3 : Сентября 15, 2004, 12:55:04 pm »

однозначно 3й вариант

// wbr
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #4 : Сентября 15, 2004, 01:04:36 pm »

Потом правда всплывут проблемы с обработкой прерываний Но если интересно, я могу дать свои наработки под Watcom под защищенку, DPMI и т.п. Я даже делал обработку прерываний под DOS в защищенном режиме (без промежуточного кода обработчика в 16-битовом сегменте) Эх времена были ... адские ... :-D
Записан

klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #5 : Сентября 15, 2004, 01:40:23 pm »

а какие собственно проблемы с обработкой прерываний? у меня в свое время через DPMI все отлично работало и под dos4gw и под dos4g и еще под чем-то уже забыл как зовут того зверька. перехватывалась и обрабатывалась практически вся AT периферия. разве что за исключением флопика, да и то потому, что он тогда никому не упирался смотрим pdf на DPMI там все есть.

ps: конечно, у меня никаких исходников не сохранилось за давностью времени и отсутствием необходимости.

// wbr
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #6 : Сентября 15, 2004, 02:01:23 pm »

тот зверек часом не pharlap назывался?
Записан
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #7 : Сентября 15, 2004, 02:06:12 pm »

---cut---
тот зверек часом не pharlap назывался?
---cut---

нет, PharLap я не трогал. то был или pmode32 или что-то в этом духе. с открытыми исходниками и все такое. при его скромном размере [исходников] он держал почти весь DPMI 1.0. весьма приличный продукт для своего класса. потом еще было штук пять каких-то экстендеров но я их имена уже забыл.. слава богу.

// wbr
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #8 : Сентября 15, 2004, 02:06:40 pm »

klalafuda
а какие собственно проблемы с обработкой прерываний?

Скорость.

При начальном обработчике в 16-bit PM и последующем перебрасывании в 32-bit PM уходило до 200,000-300,000 тактов под DOS4GW, так что уже было больно обрабатывать 3000 прерываний в секунду - под остальное не оставалось времени.

Правда процессоры нынче другие Это не 486DX2-66 Вот тогда я сделал один хак, чтобы прерывания попадали сразу в 32bit mode под DPMI. В фоне играл музыку на Covox'е с частой 32KHz под защищенкой
Записан

lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #9 : Сентября 15, 2004, 02:08:00 pm »

MikeP
тот зверек часом не pharlap назывался

Кто хоть раз делал что-то под pharlap это имя в суе не вспоминают а тихо крестятся ...
Записан

klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #10 : Сентября 15, 2004, 02:09:22 pm »

с какой это стати обработчик начинал работать в 16bit PM? у меня *все* жило в чистом flat 32bit PM включая ессно и обработчики IRQ. или ты о каких-то других прерываниях?

// wbr
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #11 : Сентября 15, 2004, 02:16:33 pm »

klalafuda
с какой это стати обработчик начинал работать в 16bit PM

Потому что это DOS extender :-/ Все перехваченные прерывания средствами DPMI создавали в 16-bit сегменте кусочек, который потом делал jump в protected 32bit. А дальше ты ждал пока управление дойдет до тебя. Свитч протектед режимов был очень тормозной. По другому нельзя было. RTFM ?
klalafuda
у меня *все* жило в чистом flat 32bit PM

Ты просто этого не видел Для того DPMI и было.
klalafuda
включая ессно и обработчики IRQ. или ты о каких-то других прерываниях?

Все о них родимых, никаких других я не вспоминаю
Записан

klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #12 : Сентября 15, 2004, 02:20:20 pm »

---cut---
Потому что это DOS extender :-/ Все перехваченные прерывания средствами DPMI создавали в 16-bit сегменте кусочек, который потом делал jump в protected 32bit. А дальше ты ждал пока управление дойдет до тебя. Свитч протектед режимов был очень тормозной. По другому нельзя было. RTFM ?
---cut---

что-то я этого хоть убей не помню. afair грамотный экстендер просто настраивал IDT и все. на кой ему в IDT 16bit сегменты? когда через DPMI я ему говорил, что ставлю обработчик на *IRQ* -> я полностью его обслуживаю и нет необходимости делать цепочку на дос или еще какой изврат в этом духе.

// wbr
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #13 : Сентября 15, 2004, 02:25:21 pm »

Да, в голове что-то перемешалось, все наоборот 32->16. Вот, нашел толковое объяснение

Since all hardware interrupts go through the DPMI host first, you can always get away with installing only a protected-mode handler. However, as you can see by the previous example, a lot of switches between protected-mode and real mode can occur and if the interrupts happen at a high frequency (like for instance more than 10Khz), then the overhead of the interrupt reflection from real to protected-mode might be too painful, and you should consider installing a real-mode interrupt handler in addition or in replacement of the protected-mode one. Such a real mode handler will be called BEFORE the interrupt gets to the DPMI host and will treat the interrupt entirely in real-mode.

http://www.delorie.com/djgpp/doc/ug/interrupts/inthandlers2.html
Записан

lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #14 : Сентября 15, 2004, 02:27:04 pm »

Вот от туда же, но очень хорошо сказано

As you recall, hardware interrupts can occur at any time, be it in real-mode or in protected-mode. We've also seen that this usually originates time-consuming mode switches. 'What?!? How do you expect me to build my ultra-hyper-mega blaster 3D engine that will really beat the crap out of quake3 and alikes if protected-mode is so SLOWWWWWW?' No need to start whining because you've several different solutions at your disposal to compensate that handicap. In the end, your protected-mode programs will run faster than any real-mode ones you've come up with. Do you doubt me? Well, if your program is really hungry for speed you can install a protected-mode interrupt handler, or place a real-mode handler in conventional memory that will be called BEFORE the interrupt gets to the DPMI host, depending on where your application spends the most time. If it's a DOS I/O bound program, the real-mode handler will run faster as no mode switch is necessary. On the other hand, if the application mostly swims in protected-mode waters, you can write a true protected-mode handler that, as you can easily guess, will execute sooner than its real-mode brother. Also, if you're feeling really adventurous or are forced by the circumstances, you can hook an interrupt with both protected-mode and real-mode handlers but be sure to hook the protected-mode one first as otherwise it will modify the real-mode one. Also, you should know that some DPMI hosts don't allow you to hook the real-mode interrupt and some call both handlers no matter what.
Записан

Страниц: [1] 2
  Печать  
 
Перейти в: