🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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?
#2
Author: Udo Thielert
Date: Mon, 08 Apr 1996 18:51
74 lines
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?
#3
Author: haller
Date: Tue, 09 Apr 1996 01:05
13 lines
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?
#4
Author: Holger Veit
Date: Tue, 09 Apr 1996 08:59
28 lines
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