Neuer User: DOSferatu

Stellt Euch der DOS-Forum Community vor!

Re: Neuer User: DOSferatu

Beitragvon wobo » Do 6. Jan 2011, 08:28

freecrac hat geschrieben:[...]
Grundsätzlich also [DS]*16+10008h, oder?

Ja richtig. Doch wenn DS = 0 ist, dann fehlt in deinem Offset eine Null um damit die Adresse 1MB+8 Byte zu bilden.

[...]

Zum Testen ob DS und ES erweitert sind solltest du aber eine Adresse oberhalb von 10FFEFh verwenden.

Dirk


Jetzt verstehe ich Dich nicht. Ob ich auf eine Adresse über 1 MB zugreifen kann, hängt u.a. auch von der Frage ab, ob A20 enabled ist.

Darum ging es mir gar nicht. Ich wollte tatsächlich auf eine Adresse im konventionellen Ram (<1MB) zugreifen. Dafür langt es, wenn mein Offset größer als 64k ist, bei 10008h habe ich ein Offset von 64k+8byte. Ich greife dann auf das 9. byte im "zweiten" 64k-Segment zu. Das kann nicht klappen, wenn die Segmentbeschreiber für DS und ES auf 64k-Segmente zeigen. Das kann nur klappen, wenn der Segmentbeschreiber eben auf ein Segment von mehr als 64k zeigt. Da es bei mir unter betimmten Umständen geklappt hat, ohne dass ich die Segmentbeschreiber verändert habe, lag meiner Ansicht nach an himem.sys. Meine Aussage, dass himem.sys (unter bestimmten Umständen) DS und ES auf 4G setzt, ist natürlich nicht bewiesen, sondern (wieder nur) gemutmaßt. Es zeigt mir aber, dass himem.sys (unter bestimmten Umständen) die Segmentbeschreiber für DS und ES auf Segmente >64k setzt. Dies bedeutet für mich, dass nach MS (Betriebssystemhersteller!) die Größe der Datensegmentbeschreibung undefiniert ist. Das Setzen von 4G ist daher keine "Illegalität".

wobo
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Neuer User: DOSferatu

Beitragvon freecrac » Do 6. Jan 2011, 12:16

wobo hat geschrieben:
freecrac hat geschrieben:[...]
Grundsätzlich also [DS]*16+10008h, oder?

Ja richtig. Doch wenn DS = 0 ist, dann fehlt in deinem Offset eine Null um damit die Adresse 1MB+8 Byte zu bilden.

[...]

Zum Testen ob DS und ES erweitert sind solltest du aber eine Adresse oberhalb von 10FFEFh verwenden.

Dirk


Jetzt verstehe ich Dich nicht. Ob ich auf eine Adresse über 1 MB zugreifen kann, hängt u.a. auch von der Frage ab, ob A20 enabled ist.

Darum ging es mir gar nicht. Ich wollte tatsächlich auf eine Adresse im konventionellen Ram (<1MB) zugreifen.

Ach so.

Dafür langt es, wenn mein Offset größer als 64k ist, bei 10008h habe ich ein Offset von 64k+8byte. Ich greife dann auf das 9. byte im "zweiten" 64k-Segment zu. Das kann nicht klappen, wenn die Segmentbeschreiber für DS und ES auf 64k-Segmente zeigen. Das kann nur klappen, wenn der Segmentbeschreiber eben auf ein Segment von mehr als 64k zeigt.

Na klar, daran habe ich gar nicht gedacht.

Da es bei mir unter betimmten Umständen geklappt hat, ohne dass ich die Segmentbeschreiber verändert habe, lag meiner Ansicht nach an himem.sys. Meine Aussage, dass himem.sys (unter bestimmten Umständen) DS und ES auf 4G setzt, ist natürlich nicht bewiesen, sondern (wieder nur) gemutmaßt. Es zeigt mir aber, dass himem.sys (unter bestimmten Umständen) die Segmentbeschreiber für DS und ES auf Segmente >64k setzt. Dies bedeutet für mich, dass nach MS (Betriebssystemhersteller!) die Größe der Datensegmentbeschreibung undefiniert ist.

Ich werde das auch bald mal testen.

Das Setzen von 4G ist daher keine "Illegalität".

wobo

Es ist aber schon sonderbar das die Rede davon ist das bestimmte Bios-Routinen ein wrap-around vorraussetzen. Welche das aber genau sind konnte ich noch nicht herausfinden. Möglicherweise gibt es solche Bios-Routinen gar nicht mehr auf 80386+.

Ich habe auch schon mal Debugregister(dr0-dr3) zweckentfremdet um dort einen Wert zwischenzuspeichern, in der Annahme das zwei Zugriffe(schreiben/lesen) darauf schneller vollzogen werden als zwei Ramzugriffe.
Wenn man dann allerdings mit Debug versucht die Anwendung einzuladen und Haltepunkte setzt, dann kann die Anwendung innerhalb von Debug nicht mehr richtig funktionieren.

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitragvon DOSferatu » Do 6. Jan 2011, 12:46

Hm... Ich benutze aber teilweise Wraparounds beim Programmieren. Außerdem benutze ich gelegentlich auch mal die 16 oberen Bits der Exx Register zum Retten von Werten etc. Bisher hatte ich da zwar noch keine Probleme, aber das kann Zufall sein.
Heißt das nun, wenn ich HIMEM.SYS benutze UND die 16 oberen Bits der Register EBX, EBP, ESI und EDI irgendwie benutze oder zweckentfremde, daß ich dann Probleme kriege? Dachte immer, im 16Bit-Address-Mode wäre das kein Problem, da dort ja per Standard 16-Bit-Addressing eingestellt ist und man nur mit Prefix-Byte (67h - das man ja sowieso normalerweise nicht benutzt, weil im RealMode/V86-Mode keine 32-Bit Adressierung möglich) die 32bit Adressierung einschaltet.

Also im Klartext: Kann mir irgendein Mist passieren, wenn z.B:
- HIMEM.SYS vorher von mir benutzt wurde
- Ich dann irgendwann ESI auf 12345678h gesetzt habe
- Ich mov AX,ES:[SI] mache, um von Adresse ES:5678h ein Wort nach AX holen will?
(Also im Klartext: WIrd dann etwa versucht, von Adresse ES*16+12345678h zu laden?)

Wie gesagt: Bisher hatte ich dergleichen Probleme nicht, aber hoffentlich war das nicht nur ein Zufall. Ich benutze eben auch im RealMode die 32-Bit-Register (und die zusätzlichen Segmentregister FS und GS).
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Neuer User: DOSferatu

Beitragvon wobo » Do 6. Jan 2011, 15:56

DOSferatu hat geschrieben:Hm... Ich benutze aber teilweise Wraparounds beim Programmieren. Außerdem benutze ich gelegentlich auch mal die 16 oberen Bits der Exx Register zum Retten von Werten etc. Bisher hatte ich da zwar noch keine Probleme, aber das kann Zufall sein.
Heißt das nun, wenn ich HIMEM.SYS benutze UND die 16 oberen Bits der Register EBX, EBP, ESI und EDI irgendwie benutze oder zweckentfremde, daß ich dann Probleme kriege? Dachte immer, im 16Bit-Address-Mode wäre das kein Problem, da dort ja per Standard 16-Bit-Addressing eingestellt ist und man nur mit Prefix-Byte (67h - das man ja sowieso normalerweise nicht benutzt, weil im RealMode/V86-Mode keine 32-Bit Adressierung möglich) die 32bit Adressierung einschaltet.

Also im Klartext: Kann mir irgendein Mist passieren, wenn z.B:
- HIMEM.SYS vorher von mir benutzt wurde
- Ich dann irgendwann ESI auf 12345678h gesetzt habe
- Ich mov AX,ES:[SI] mache, um von Adresse ES:5678h ein Wort nach AX holen will?
(Also im Klartext: WIrd dann etwa versucht, von Adresse ES*16+12345678h zu laden?)

Wie gesagt: Bisher hatte ich dergleichen Probleme nicht, aber hoffentlich war das nicht nur ein Zufall. Ich benutze eben auch im RealMode die 32-Bit-Register (und die zusätzlichen Segmentregister FS und GS).


ich denke nicht, dass es da Probleme geben kann. Habe ich auch so schon gemacht und keine Probleme gehabt. Wenn Du explizit sagst: mov ax, es:[si] dann sollte der Assembler/Basm auch nur si verwenden.

Wenn ich TD richtig verstehe (ich verwende seit ein paar Tagen zum ersten Mal in meinem Leben einen Debugger), dann sagt er mir auch eindeutig, dass nur si, und nicht esi zur Adressbildung verwendet wurde.

Mit db $67 schaltest Du ja auch nicht die CPU (global) in den 32bit-Mode, sondern sagst: CPU verwende für nachfolgenden Befehl ausnahmsweise die 32bit-Variante (wenn ich das alles richtig verstanden habe). Und db $67 verwendest Du ja nur, wenn Du explizit 32-bit-Adressierung, also mov ax, es:[esi] haben willst, was Du in Deinem Beispiel weder tust noch tun willst.


Ich kann mir auch kein Problem vorstellen, dass dadurch entsteht, dass himem.sys (unter bestimmten Umständen) die Segmentbeschreiber für DS und ES auf Segmente >64k einstellt. Im Normalfall werden zur Adressbildung nur die 16bit-Register verwendet, was keine Probleme gibt. 16bit-Register ist 16bit-Register und damit <64k.

Das einzige wäre, wenn man unter Dos z.B. mit mov ax,es:[esi] auf den Speicher zugriffe und davon ausginge, es gäbe immer einen Wraparound, weil Segmente
stets 64k hätten. Das geht aber im Normalfall nicht: Bei mir hängt sich immer der PC auf, wenn esi einen Wert >=64k hat. ich gehe davon aus, dass die CPU eine Exception auslöst, unter Dos aber niemand da ist, um diese zu behandeln. Es wird also niemand ein solches Programm in Umlauf bringen können, weil es sich schon beim ersten Probelauf aufhängt.

Die einzige Konstellation, bei der sich mein PC nicht aufgehängt hat, war die von mir beschriebene Situation (gebrauchter himem.sys, 386er, kein v86). Dann gab es kein Aufhängen, sondern ich konnte die Speicherstelle unter Verwendung von esi mittels eines offsets >64k auslesen. Ich habe das als Bestätigung des Gerüchts gesehen, dass himem.sys in den 4G schaltet - und zu meiner Verwunderung diesen angeschaltet läßt.


Wie gesagt, ich denke das ganze ist nicht so wild und hat keine praktischen Auswirkungen:
- Dein Wraparound erfolgt durch die Verwendung des 16bit-Registers. Die oberen Bits (16-31) bleiben unangetastet.
- Dos Programme, die mov ax, es:[esi] o.ä. verwenden und dabei davon ausgehen, die oberen 16bit würden ignoriert, wird es nicht geben.


Meine weitere Vermutung, daß himem.sys "abgeschossen" wird, wenn die Segmentbeschreiber wieder auf 64k gesetzt werden, hat sich nicht bestätigt. Offensichtlich setzt die XMS-Funktion 11 vor jedem Aufruf wieder den 4G-Mode oder es wird anderweitig die Größe der Segmente geprüft.

Damit bleibt eigentlich nur zu sagen: Flat4G/unreal ist ein von MS anerkanntes Verfahren, das auch im Zusammenspiel mit himem.sys zu funktionieren scheint.

wobo
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Neuer User: DOSferatu

Beitragvon freecrac » Do 6. Jan 2011, 17:11

wobo hat geschrieben:
DOSferatu hat geschrieben:Hm... Ich benutze aber teilweise Wraparounds beim Programmieren. Außerdem benutze ich gelegentlich auch mal die 16 oberen Bits der Exx Register zum Retten von Werten etc. Bisher hatte ich da zwar noch keine Probleme, aber das kann Zufall sein.
Heißt das nun, wenn ich HIMEM.SYS benutze UND die 16 oberen Bits der Register EBX, EBP, ESI und EDI irgendwie benutze oder zweckentfremde, daß ich dann Probleme kriege? Dachte immer, im 16Bit-Address-Mode wäre das kein Problem, da dort ja per Standard 16-Bit-Addressing eingestellt ist und man nur mit Prefix-Byte (67h - das man ja sowieso normalerweise nicht benutzt, weil im RealMode/V86-Mode keine 32-Bit Adressierung möglich) die 32bit Adressierung einschaltet.

Also im Klartext: Kann mir irgendein Mist passieren, wenn z.B:
- HIMEM.SYS vorher von mir benutzt wurde
- Ich dann irgendwann ESI auf 12345678h gesetzt habe
- Ich mov AX,ES:[SI] mache, um von Adresse ES:5678h ein Wort nach AX holen will?
(Also im Klartext: WIrd dann etwa versucht, von Adresse ES*16+12345678h zu laden?)

Wie gesagt: Bisher hatte ich dergleichen Probleme nicht, aber hoffentlich war das nicht nur ein Zufall. Ich benutze eben auch im RealMode die 32-Bit-Register (und die zusätzlichen Segmentregister FS und GS).


ich denke nicht, dass es da Probleme geben kann. Habe ich auch so schon gemacht und keine Probleme gehabt. Wenn Du explizit sagst: mov ax, es:[si] dann sollte der Assembler/Basm auch nur si verwenden.

Wenn ich TD richtig verstehe (ich verwende seit ein paar Tagen zum ersten Mal in meinem Leben einen Debugger), dann sagt er mir auch eindeutig, dass nur si, und nicht esi zur Adressbildung verwendet wurde.

Mit db $67 schaltest Du ja auch nicht die CPU (global) in den 32bit-Mode, sondern sagst: CPU verwende für nachfolgenden Befehl ausnahmsweise die 32bit-Variante (wenn ich das alles richtig verstanden habe). Und db $67 verwendest Du ja nur, wenn Du explizit 32-bit-Adressierung, also mov ax, es:[esi] haben willst, was Du in Deinem Beispiel weder tust noch tun willst.

Ich kann mir auch kein Problem vorstellen, dass dadurch entsteht, dass himem.sys (unter bestimmten Umständen) die Segmentbeschreiber für DS und ES auf Segmente >64k einstellt. Im Normalfall werden zur Adressbildung nur die 16bit-Register verwendet, was keine Probleme gibt. 16bit-Register ist 16bit-Register und damit <64k.

Genauso ist es im 16bit-Mode.

....

@DOSferatu: Auf eine Wraparound bei der Verwendung von 32bit-Offset-Register würde ich mich allerdings nicht mehr verlassen.

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitragvon DOSferatu » Fr 7. Jan 2011, 11:15

Dann ist ja alles OK.
Ich selbst benutze ja den in Borland (Turbo-)Pascal eingebauten Assembler. Der kann nur maximal 286er Code. Alles, was darüber hinausgeht (32bit-Register, FS/GS, 386er-Befehle usw.) erzeuge ich, indem ich die entsprechenden Bytes "von Hand" in den Sourcecode einfüge (db Byte und so). Ich weiß, für manche klingt das vielleicht nach Masochismus - aber erstens ist das auch nur eine Frage der Gewöhnung und zweitens kann ich so recht einfach meine ASM-Routinen mit dem darumliegenden Pascal-Code verbinden. Das Präfix-Byte 67h benutze ich ja nicht (da es im RealMode/V86-Mode sowieso keinen Sinn macht).

Und selbst wenn ich ein Programm schreibe, das quasi 100% ASM ist, brauche ich mich nicht um das "Wie mach ich eine EXE daraus?"-Problem kümmern, da es von einem "Pascal-Rahmen" umgeben ist. Natürlich ist der Nachteil, daß ich dann keine kleinen COM-Files schreiben kann, aber so Treiberzeug usw. hab ich sowieso noch nicht geschrieben und ob meine ausführbaren Programme nun *.COM oder *.EXE heißen ist mir irgendwie egal. (Ja, ich weiß, daß bei COM der aufwendige Overhead wegfällt.)
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Neuer User: DOSferatu

Beitragvon freecrac » Fr 7. Jan 2011, 12:34

DOSferatu hat geschrieben:Das Präfix-Byte 67h benutze ich ja nicht (da es im RealMode/V86-Mode sowieso keinen Sinn macht).

Auch im RealMode/V86-Mode macht ein Präfix-Byte 67h durchaus Sinn z.B. so:
Code: Alles auswählen
67 66 8D 0498   lea eax, [eax+ebx*4]

Denn sonst müsste man z.B. folgende Befehle dafür verwenden um das selbe zu erreichen:
Code: Alles auswählen
shl ebx, 2
add eax, ebx
shr ebx, 2

Alle Adressberechnungen (mit oder ohne Präfix-Byte 67h) werden schneller ausgeführt als Integerberechnungen.
So kann man auch ein "lea eax, [eax+1]" anstelle von "inc eax", oder ein "lea si, [si+1234h]" anstelle von "add si, 1234h" verwenden.
Doch Flags werden dabei nicht gesetzt!

ftp://ftp.sac.sk/pub/sac/text/asm86faq.zip->ASM86FAQ.TXT
"Seit den 386ern "zweckentfremden" viele Programmierer LEA aber auch z.B. für mathematische Kettenoperationen, oder Adressberechnungen mit mehreren Komponenten,
da LEA in vielen Situationen (s. dazu auch OPT0004) um ein Vielfaches schneller ist, als entsprechende andere Befehle bzw. Befehlssequenzen."
Code: Alles auswählen
                                                          O D I T S Z A P C
 ┌────────────────────────────────────────────────────────┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
 │ LEA - Load Effective Address                           │-----------------│
 └────────────────────────────────────────────────────────┴─┴─┴─┴─┴─┴─┴─┴─┴─┘

   Befehl             Pipe   P5    486    386   286   86        Opcode

   LEA r16, m          UV    1     1      2     3     2+EA      8D /r
   LEA r32, m          UV    1     1      2     -     -         8D /r


   Pseudocode:

     if OperandSize = 16 then
       if AddressSize = 16 then
         r16 = Addr(m)
       else
         r16 = Addr(m) AND 0000ffffH
       endif
     else
       if AddressSize = 16 then
         r32 = Addr(m) AND 0000ffffH
       else
         r32 = Addr(m)
       endif
     endif


   Beschreibung:

     LEA berechnet  die effektive Adresse von SRC,  d.h. den relativen Offset
     vom  entsprechenden Segmentbeginn  bis zur Speicheradresse SRC  und legt
     diesen in DEST ab.

     HINWEIS: Wird LEA r16, m auf ein USE32-Segment, oder LEA r32, m  auf ein
              USE16-Segment angewandt, erhält man immer nur die unteren 16bit
              des Offsets... ;)

     HINWEIS: Einige Assemblerpakete  wandeln LEA-Instructions,  die sich auf
              eine konstante effektive Speicheradresse beziehen, u.U. automa-
              tisch (i.d.R. einstellungsabhängig) in MOV-Instructions um,  um
              den RunTime-Code zu verkürzen (MOV ist in diesem Fall meist ein
              Byte kürzer als LEA).

     LEA wurde früher  fast ausschließlich für Initialisierungen vor der Aus-
     führung von z.B. XLAT- oder String-Instructions (LODS, STOS, MOVS, usw.)
     benutzt.

     Seit den 386ern "zweckentfremden" viele Programmierer LEA aber auch z.B.
     für mathematische Kettenoperationen, oder Adressberechnungen mit mehrer-
     en Komponenten,  da LEA in vielen Situationen  (s. dazu auch OPT0004) um
     ein Vielfaches schneller ist, als entsprechende andere Befehle  bzw. Be-
     fehlssequenzen.

     Übrigens,  SRC sollte vom Assembler  immer als Speicheradresse interpre-
     tiert werden können, auch wenn nur Register verwendet werden, ansonsten
     verabschiedet sich die CPU mit Interrupt 6 (Invalid, #UD)... &)


   Exceptions:

     RM   Int 6 (Invalid), Int 13 (Wrap)
     VM   Int 6 (Invalid), Int 13 (Wrap)
     PM   #UD

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitragvon wobo » Mo 17. Jan 2011, 19:34

freecrac hat geschrieben:
wobo hat geschrieben:
Kennst Du eine Anwendung, die im 32bit-Real-Mode läuft?

Nein solche Anwendungen kenne ich persöhnlich auch noch nicht.

...
Dirk


Meine Leseempfehlung hierzu:

http://board.flatassembler.net/topic.php?t=11940
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Neuer User: DOSferatu

Beitragvon freecrac » Di 18. Jan 2011, 08:45

wobo hat geschrieben:
freecrac hat geschrieben:32bit-Real-Mode-Anwendung.
Nein solche Anwendungen kenne ich persöhnlich auch noch nicht.


Meine Leseempfehlung hierzu:

http://board.flatassembler.net/topic.php?t=11940

Die Idee den Unrealmode mit dem 32Bit-Mode zu kombinieren und vor jedem Bios- und DOS-Aufruf in den 16Bit-Mode zu schalten und danach wieder zurück finde ich gar nicht mal so schlecht.
Nur habe ich keine 32Bit Interrupt-Tabelle für DOS und ohne müsste man alle auftretenden IRQs im 32Bit-Mode verhindern.

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Neuer User: DOSferatu

Beitragvon drzeissler » So 11. Sep 2016, 09:37

Hi DOSferatu,

könntest Du mir bitte einen Tipp geben, wie ich das hier mache?

Hier der Thread: http://forum.classic-computing.de/index ... post100929
Hier der Link: http://forum.classic-computing.de/index ... e5ccd7009d

Zusammenfassung:

STARS.zip enthält ein simples Starfield. Das läuft mit CGA Emulation aber fehlerhaft.
Da der ASM-Code dabei ist, frage ich mich, wie ich das Teil auf Hercules "UMBIEGEN"
kann, wenn ich denn das hier weis:

2.1.3 HGC (Hercules Graphics Card)

Der Wunsch der Anwender nach Grafikadaptern mit hoher Auflösung veranlaßte einige Firmen Grafikkarten mit dieser Option
herzustellen. Dabei setzte sich Hercules Computer Technology mit ihrer 1982 eingeführten Hercules Graphics Card durch, die
sich daraufhin schnell zum führenden Standart für Monochrom-Adapter entwickelte. Die HGC emuliert im Textmodus den MDA
vollständig und ist deshalb auch zu älterer Software kompatibel. Die Karte ist mit 64 KByte ausgestattet und überschneidet
damit den Adressraum der CGA-Karte. Um weiterhin 2 Karten parallel betreiben zu können kann man die Speicherseite ab
0x000B8000 ausblenden. Im gegensatz zum Textmodus hat der Grafikmodus im Vertikalen 2 Rasterzeilen weniger da die
letzten beiden für den Vertikalen Rücklauf des Elektronenstrahl der Bildröhre verwendet werden.

Code: Alles auswählen
                  Textmodus      Grafikmodus
Adresse           0x000B0000     0x000B0000
Speicher          4 KByte        64 KByte
Seiten            1              2
Controller        CRTC 6845      CRTC  6845
CRTC Ports        0x03B0-0x03BF  0x03B0-0x03BF
Zeichenmatrix     9x14           9x14
effektiv          7x9            7x9
max. Auflösung    720x350        720x348
max. Zeichen      80x25          80x25
max. Farben       mono           mono
Monitor           digital        digital
Bildfrequenz      50 Hz          50 Hz
Zeilenfrequenz    18,432 kHz     18,432 kHz
Punktfrequenz     16,257 MHz     16,257 MHz


Danke und Gruß
Doc

PS: Gibt EINDEUTIG zu wenig Dinge für Hercules :(
CPU: 486 DX2/66 MOBO: SNI-D882 RAM: 3x16MB - FDD: 3,5" 1,44MB HDD: 6,4GB Seagate ISA(1): Audican32Plus PCI(1): 3com TX 905 OS: MsDos622 - Win95a - WinNT 3.51
drzeissler
DOS-Gott
 
Beiträge: 3045
Registriert: Mo 8. Feb 2010, 16:59

Re: Neuer User: DOSferatu

Beitragvon DOSferatu » Mo 12. Sep 2016, 21:00

@drzeissler:
Ich schau's mir am Wochenende mal an.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Neuer User: DOSferatu

Beitragvon drzeissler » Mo 12. Sep 2016, 21:02

Danke, ich bin leider noch nicht so weit, da selber was dran zu tüfteln. Aber ich habe schon ein wenige gelesen.--
CPU: 486 DX2/66 MOBO: SNI-D882 RAM: 3x16MB - FDD: 3,5" 1,44MB HDD: 6,4GB Seagate ISA(1): Audican32Plus PCI(1): 3com TX 905 OS: MsDos622 - Win95a - WinNT 3.51
drzeissler
DOS-Gott
 
Beiträge: 3045
Registriert: Mo 8. Feb 2010, 16:59

Vorherige

Zurück zu User-Vorstellungen

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste