Thread View: de.comp.os.os2.programmer
3 messages
3 total messages
Started by Udo Thielert
Mon, 08 Apr 1996 18:51
Problem: IOPL Segment - direkter Speicherzugriff?
Author: Udo Thielert
Date: Mon, 08 Apr 1996 18:51
Date: Mon, 08 Apr 1996 18:51
74 lines
2841 bytes
2841 bytes
An Alle die mir helfen koennen:
Vorab: Ich bitte ich um Verstaendniss wenn 2 adressierte Gruppen/Bretter
evtl. nicht die richtigen Zielgruppen sind.
Problemstellung:
Ich moechte unter OS/2 direkt auf das shared RAM einer PC-Karte zugreifen.
Es sind keine Portzugriffe notwendig und daher koennen die allgemeinen
Device-Driver "testcfg.sys" oder "fastio.sys" (written by Holger Veit)
nicht herangezogen werden.
Angestrebte Loesung:
1) Entweder ueber einen erhaeltlichen allgemeinen Device-Driver, der den
Zugriff auf Adressen im unteren Speicherbereich (z. B. D000:0000
-E000:0000) erlaubt. Dieser Treiber kann als Sourcecode (C o. Ass.)
oder als fertiger Treiber vorliegen. Eine (kurze) Doku dazu, waere
hilfreich. Kennt jemand eine Adresse/Ort, wo so etwas zu finden ist?
2) Ein Stueck Sourcecode, gekapselt in einer DLL, das den Zugriff auf das
shared RAM ermoeglicht. Dieser Sourcecode sollte mit dem WATCOM-
Compiler/Linker Ver. 10.5 verwendbar sein.
Eigene Versuche:
Ich habe bereits mehrere erfolglose Versuche, dieses Problem zu loesen,
hinter mir [Frust on].
Folgenden Weg versuchte ich einzuschlagen:
Schreibe eine DLL mit einer Funktion (cpy_mb_to_pad()), die noch keinen
Speicherzugriff macht.
Diese Funktion wird mit folgender pragma-Anweisung in ein eigenes Segment
gelegt.
#pragma alloc_text (U_SEG, cpy_mb_to_pad);
Als DLL compiliert.
Mit folgender Anweisung gelinkt:
(komplett und wegen der Uebersicht untereinander)
wlink d all
sys os2v2
dll seg 'U_SEG' iopl
op m
exp cpy_mb_to_pad_
op maxe=25
op q
op symf
op de 'DLL for Mailbox access'
op one mbio.lk1
Mit folgender Anweisung wird eine DLL-Lib erzeugt:
wlib -n -b mbio.lib +mbio.dll
Ein kurzes Hauptprogramm benutzt diese Funktion.
Sobald diese Funktion angesprungen wird, kommt die Fehlermeldung sys3175
(access violation exception) und das Programm wird beendet.
Wie gesagt, die Funktion wird nur im benannten Segment aufgerufen und
schon geht's in die Hosen.
Experimente verschiedenster Art brachten keinen Erfolg.
Fragen:
Mal abgesehen davon, dass dies nicht der saubere Weg ist, gibt es da einen
Denkfehler meinerseits?
Liegt evtl. ein Bug im WATCOM Compiler/Linker etc. vor?
Oder habe ich nur eine (grosse) Kleinigkeit nicht beachtet?
Viele Fragen auf einmal, ich hoffe eine Anwort die mir weiterhilft ist
dabei.
Besten Dank im voraus...
mfg
Udo
--
Udo Thielert
eMail: ut@utcom.prima.ruhr.de
## CrossPoint v3.1 R ##
Re: Problem: IOPL Segment - direkter Speicherzugriff?
Author: haller
Date: Tue, 09 Apr 1996 01:05
Date: Tue, 09 Apr 1996 01:05
13 lines
1155 bytes
1155 bytes
In <66UdPtU5KrB@utcom.prima.ruhr.de>, ut@utcom.prima.ruhr.de (Udo Thielert) writes: >An Alle die mir helfen koennen: >Problemstellung: >Ich moechte unter OS/2 direkt auf das shared RAM einer PC-Karte zugreifen. >Es sind keine Portzugriffe notwendig und daher koennen die allgemeinen >Device-Driver "testcfg.sys" oder "fastio.sys" (written by Holger Veit) >nicht herangezogen werden. Schon einen tieferen Blick aif VioGetPhysBuf() geworfen ? Doku dazu in PRCP.INF. Allenfalls muss mit dem 16-Bit Thunking in den Headern etwas aufgepaát werden. Aber es sollte damit klappen. cu/2 Pat (haller@zebra.fh-weingarten.de)
Re: Problem: IOPL Segment - direkter Speicherzugriff?
Author: Holger Veit
Date: Tue, 09 Apr 1996 08:59
Date: Tue, 09 Apr 1996 08:59
28 lines
2104 bytes
2104 bytes
In article <4kcd58$j01@zebra.fh-weingarten.de>, haller@zebra.fh-weingarten.de@zebra.fh-weingarten.de writes:
|> In <66UdPtU5KrB@utcom.prima.ruhr.de>, ut@utcom.prima.ruhr.de (Udo Thielert) writes:
|> >An Alle die mir helfen koennen:
|> >Problemstellung:
|> >Ich moechte unter OS/2 direkt auf das shared RAM einer PC-Karte zugreifen.
|> >Es sind keine Portzugriffe notwendig und daher koennen die allgemeinen
|> >Device-Driver "testcfg.sys" oder "fastio.sys" (written by Holger Veit)
|> >nicht herangezogen werden.
Dann nimm nicht fastio.sys, sondern xf86sup.sys; dieser enthaelt einen
Treiber namens MAP$, der beliebiges physikalisches RAM in den Adressraum
eines Prozesses mappen kann. http://borneo.gmd.de/~veit/os2/xf86sup.html
fuer eine aeltere (aber funktionsfaehige) Version mit Source; neueste Version
(1.420) ist Teil von XFree86/OS2 (keine Aenderungen im MAP$ und FASTIO$ -Teil).
|> Schon einen tieferen Blick aif VioGetPhysBuf() geworfen ? Doku dazu in PRCP.INF.
|> Allenfalls muss mit dem 16-Bit Thunking in den Headern etwas aufgepaát werden.
|> Aber es sollte damit klappen.
VioGetPhysBuf benutzt screen$ und ist damit einschraenkt auf Video-RAM-Bereiche.
--
Dr.-Ing. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD - German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Information Technology| Fax: (+49) 2241 14 2242
| | / Schloss Birlinghoven | *it* is there:
| |/ D-53754 Sankt Augustin, Germany | at ftp.xfree86.org in
WWW: http://borneo.gmd.de/~veit/ | /pub/XFree86/beta/OS2/
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads