Forum: PC-Programmierung x86, 16Bit, DOS, Assembler: Bios Memory mapping?


von cppbert (Gast)


Lesenswert?

kann mir jemand sagen was unter DOS/16Bit/Real-Mode an 0xF000:0xC000 
steht?

laut diesem Bild und anderen Seiten im Internet
https://www.phatcode.net/res/155/images/fig1-1_i.png

liegt dort das kopierte BIOS - ein 64K Block von F000:0000-F000:FFFF

ist ein Initialisierungs-Code aus einem alten DOS-Spiel
jemand eine Idee was an der Speicherstelle steht?

IDA Ausgabe (mit Offset, Opcode und Assembler-Anzeige)
1
seg000:19E4                 sub_34   proc near               ; CODE XREF: seg000:1BB8
2
seg000:19E4 06                       push    es
3
seg000:19E5 B8 00 F0                 mov     ax, 0F000h
4
seg000:19E8 8E C0                    mov     es, ax
5
seg000:19EA                          assume es:nothing
6
seg000:19EA 33 C0                    xor     ax, ax
7
seg000:19EC 26 8A 0E 00 C0           mov     cl, es:0C000h   ; cl = byte ptr [0F000h:0C000h] ????
8
seg000:19F1 80 F9 21                 cmp     cl, 21h
9
seg000:19F4 75 03                    jnz     short loc_245
10
seg000:19F6 B8 40 00                 mov     ax, 40h
11
seg000:19F9
12
seg000:19F9                 loc_245:                         ; CODE XREF: sub_34+10
13
seg000:19F9 07                       pop     es
14
seg000:19FA                          assume es:nothing
15
seg000:19FA 2E 08 06 02 02           or      byte ptr cs:dword_319+1, al
16
seg000:19FF C3                       retn
17
seg000:19FF                 sub_34   endp

und nur damit sich hier keiner beteiligen muss ​der sich gar nicht 
auskennt:

-das ist ganz alte Segment/Offset basierte Adressierung - das müssen wir 
nicht hier im Gespräch erörtern

-ich kann 16/32/64 Bit x86 Assembler - nur mit dem alten Memory mapping 
haperts (im Dosbox Source gibt es dazu auch nix)

-der Code ist >31 Jahre alt, läuft unter DOS - mir ist klar das es ein 
veraltetes System ist und es neueres gibt

-ich suchen keine Disassembler: ich kann Problemlos alles 
disassemblieren (mit meine IDA-Lizenz, Ghidra, Shell-Storm, und,und,und)

-ich suchen keinen Assembler/Kompiler: ich kann Problemlos alles 
assemblieren und kompilieren was aus der Zeit stammt

-das ist nur ein Oldschool-Ausflug: normalerweise schreibe ich nur 
32/64Bit Software unter Windows und Linux

von cppbert (Gast)


Lesenswert?

noch mal als Shell-Storm disassembly
1
0x0000000000000000:  06                push es
2
0x0000000000000001:  B8 00 F0          mov  ax, 0xf000
3
0x0000000000000004:  8E C0             mov  es, ax
4
0x0000000000000006:  33 C0             xor  ax, ax
5
0x0000000000000008:  26 8A 0E 00 C0    mov  cl, byte ptr es:[0xc000]
6
0x000000000000000d:  80 F9 21          cmp  cl, 0x21
7
0x0000000000000010:  75 03             jne  0x15
8
0x0000000000000012:  B8 40 00          mov  ax, 0x40
9
0x0000000000000015:  07                pop  es
10
0x0000000000000016:  2E 08 06 02 02    or   byte ptr cs:[0x202], al
11
0x000000000000001b:  C3                ret

würde ich so portieren
1
uint8_t var0x202; // durch anderen Code gesetzt
2
...
3
uint8_t cl = *MK_FP(0xf000, 0xc000);
4
uint8_t al = ( cl != 0x21 ) 0 ? 0x40;
5
var0x202 |= al;
6
...

die Frage ist: was kam da ~1990 raus?

von Mario M. (thelonging)


Lesenswert?

"Copyright messages are commonly stored at locations F000:E000, 
F000:C000, and F000:0000."
https://jeffpar.github.io/kbarchive/kb/061/Q61421/

Das soll wohl ein Test sein, ob das Programm auf einem Computer eines 
bestimmten Typs läuft.

cppbert schrieb:
> or      byte ptr cs:dword_319+1, al

Könnte sich um selbstmodifizierenden Code handeln.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

cppbert schrieb:
> kann mir jemand sagen was unter DOS/16Bit/Real-Mode an 0xF000:0xC000
Viel zu lange ist es her.

0xF000: 0xC000 => 0x00F0C000

Der Real-Mode hat aber nur 20Bit (0x000FFFFF). Damit sollten einige Bit 
wegfallen. Hier lauert aber auch noch irgendwo die böse A20-Gate Affäre.
- https://en.wikipedia.org/wiki/A20_line

Nach dieser Liste hier:
- https://wiki.osdev.org/Memory_Map_(x86)
- 0x00F00000 - 0x00FFFFFF Possible memory mapped hardware - ISA Memory 
Hole 15-16MB

3: The "ISA Memory Hole" (from 0x00F00000 to 0x00FFFFFF) was used for 
memory mapped ISA devices (e.g. video cards). Modern computers have no 
need for this hole, but some chipsets still support it (as an optional 
feature) and some motherboards may still allow it to be enabled with 
BIOS options, so it may exist in a modern computers with no ISA devices.

von Mario M. (thelonging)


Lesenswert?

Irgend W. schrieb:
> Viel zu lange ist es her.
> 0xF000: 0xC000 => 0x00F0C000

Das entspricht der Adresse 0xFC000.
https://de.m.wikipedia.org/wiki/Segmentierung_(Speicherverwaltung)#Intels_x86-Prozessoren_im_Real-Mode

von W.S. (Gast)


Lesenswert?

cppbert schrieb:
> laut diesem Bild und anderen Seiten im Internet...
> liegt dort das kopierte BIOS - ein 64K Block von F000:0000-F000:FFFF

Da ist nix kopiert, woher denn auch?
Wa sich dort klassischermaßen befindet, sind
- das eigentliche ROM-BIOS
- eventuell noch der residente BASIC-Interpreter

Das Ganze hängt mit dem Startverhalten des 8086 zusammen, der startet 
nämlich nicht ab 0 sondern am Speicherende (so, wie es damals auch 
einige andere Arcitekturen gemacht haben) - und es hat auch nichts mit 
DOS zu tun.

W.S.

Beitrag #6767352 wurde vom Autor gelöscht.
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Hallo cppbert (Gast)

Ich hatte früher sehr viele Steuerungen im Assembler bis hin zum 
PentiumII programmiert.
Heute verwende ich keine x86 CPU's mehr sondern mach eigene MPU's (oft 
auch in FPGA's die anwendungsspezifisch funktionieren.
Oder verwende auch die MSP430 dazu.

Aber wie von einem Vorposter schon beschrieben, meinte ich dass dies 
tatsächlich ein Biosauszug ist, um die damaligen lahmen PROM in den RAM 
zu Kopieren.

Ich habe gelesen dass du Alles Werkzeug dazu hast,
Aber trotzdem möchte ich dir meine Erfahrung von damals noch Mitteilen.

Ich hatte damals solche Funktionen mit dem Resourcer analysiert.
um mich nicht Unnötig mit den Einsprungpunkten & Co apzuplagen.

Wenn du Interesse hast kann ich ja mal auf den alten Backups nach dem 
Resourcer suchen und gegebenenfalls den Link dazu einstellen. Irgend 
wo im WEB oder WEBARCHIV müsste der noch zu Finden sein.
Ansonsten habe ich den sicher auch auf einem Backup.
Nur wen's interessiert ;-)

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Mario M. schrieb:
> Irgend W. schrieb:
>> Viel zu lange ist es her.
>> 0xF000: 0xC000 => 0x00F0C000
>
> Das entspricht der Adresse 0xFC000.

Jo, hast recht damit. Ich hatte um zwei Hex-Stelle und somit um eine 
zuviel  geschiftet:-(

von Rolf M. (rmagnus)


Lesenswert?

Patrick L. schrieb:
> Aber wie von einem Vorposter schon beschrieben, ist dies tatsächlich ein
> Biosauszug, um die damaligen lahmen PROM in den RAM zu Kopieren.

Das nannte man Shadow RAM. Bei einigen Rechnern konnte man auch über das 
BIOS-Setup einstellen, ob das BIOS-ROM in den RAM kopiert oder 
stattdessen direkt in den Adressbereich gemappt werden sollte.

W.S. schrieb:
> cppbert schrieb:
>> laut diesem Bild und anderen Seiten im Internet...
>> liegt dort das kopierte BIOS - ein 64K Block von F000:0000-F000:FFFF
>
> Da ist nix kopiert, woher denn auch?

Na aus dem BIOS-Flash/ROM.

: Bearbeitet durch User
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Rolf M. schrieb:
> Das nannte man Shadow RAM.

Ja hast du recht, da ich aber grad hier im Wiki im AVR Sektor am 
Schreiben war, fiel mir das nicht ein. Danke :-D

von Mario M. (thelonging)


Lesenswert?

Es dürfte sich um das "Tandy ID Byte" handeln.
https://www.vogons.org/viewtopic.php?p=462020#p462020

von cppbert (Gast)


Lesenswert?

Mario M. schrieb:
> "Copyright messages are commonly stored at locations F000:E000,
> F000:C000, and F000:0000."
> https://jeffpar.github.io/kbarchive/kb/061/Q61421/
>
> Das soll wohl ein Test sein, ob das Programm auf einem Computer eines
> bestimmten Typs läuft.

das ist auf jeden Fall mal eine gute Forschungsrichtung
- falls ich im Folge-Code die Bedeutung des dword_319+1 verstanden haben
wir das vielleicht klarer

vielleicht irgendeine Old-School Inkompatibilität - damals war ja alles 
eine wenig schwieriger mit den ganzen BIOSen und DOS-Versionen...

> cppbert schrieb:
>> or      byte ptr cs:dword_319+1, al
>
> Könnte sich um selbstmodifizierenden Code handeln.

könnte (entfernt) möglich sein - das Program ist so eine Art 
Starter/Unpacker - der verschiedene Sound+Video-Code-Dateien im Speicher 
kombiniert und dann ausführt - um Speicherplatz auf der Diskette zu 
sparen

von cppbert (Gast)


Lesenswert?

Mario M. schrieb:
> Es dürfte sich um das "Tandy ID Byte" handeln.
> https://www.vogons.org/viewtopic.php?p=462020#p462020

das könnte es wirklich sein - Tandy wird vom dem Spiel auch supported

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> Mario M. schrieb:
>> Es dürfte sich um das "Tandy ID Byte" handeln.
>> https://www.vogons.org/viewtopic.php?p=462020#p462020
>
> das könnte es wirklich sein - Tandy wird vom dem Spiel auch supported

ja das ist es!

https://www.brutman.com/forums/viewtopic.php?f=6&t=119#p506

>>More simply, though, this thread over on the VOGONS forums says that Tandy 
>>systems have a special ID byte of 0x21 at exactly F000:C000

von cppbert3 (Gast)


Lesenswert?

Patrick L. schrieb:
> Ich hatte damals solche Funktionen mit dem Resourcer analysiert.
> um mich nicht Unnötig mit den Einsprungpunkten & Co apzuplagen.

Ich hab eine aktuelle lizensierte IDA Pro Version, dagegen ist dein 
Resourcer Steinzeittechnologie, aber trotzdem danke für dein Angebot

von Georg (Gast)


Lesenswert?

cppbert3 schrieb:
> dagegen ist dein
> Resourcer Steinzeittechnologie

Na und - die Höhlenmalereien aus der Steinzeit haben immerhin 30000 
Jahre überdauert, ich glaube nicht dass ein Tintenstrahldruck 
vergleichbares schafft. Dass etwas alt ist kann kein Totschlagsargument 
dagegen sein.

Georg

von c-hater (Gast)


Lesenswert?

cppbert3 schrieb:

> Ich hab eine aktuelle lizensierte IDA Pro Version, dagegen ist dein
> Resourcer Steinzeittechnologie, aber trotzdem danke für dein Angebot

Nun musst du bloß noch lernen, damit kompetent umzugehen...

LOL

von cppbert3 (Gast)


Lesenswert?

Georg schrieb:
> cppbert3 schrieb:
>
>> dagegen ist dein
>> Resourcer Steinzeittechnologie
>
> Na und - die Höhlenmalereien aus der Steinzeit haben immerhin 30000
> Jahre überdauert, ich glaube nicht dass ein Tintenstrahldruck
> vergleichbares schafft. Dass etwas alt ist kann kein Totschlagsargument
> dagegen sein.
> Georg

Es kommt immer darauf an welche Eigenschaften für das gewollte Ergebnis 
relevant sind - und solange man denk das eine Disassembler einfach nur 
linear disassembeln muss ist der Unterschied auch nicht erkennbar, aber 
so ist es eben einfach nicht, Disassembler die Jahrzehnte auf dem Buckel 
haben fehlen die fortschrittlichen Analysestrategien und Wissensbasis 
wie Signaturdatenbanken, oder die damaligen Systeme waren einfach nicht 
leistungsfähig genug um intensive Tiefenanalysen zu erlauben, deswegen 
sind die "Alten" algorithmisch eher schwach und unter den 5-6 aktuellen 
Tools die aktiv entwickelt werden ist der IDA Pro einfach immer noch 
sehr sehr gut

Wer vor 20 Jahren DOS Software disassembliert hat wird erstaunt sein was 
ein aktueller IDA Pro aus den ollen Bytewolken zaubern kann

von cppbert3 (Gast)


Lesenswert?

c-hater schrieb:
> Nun musst du bloß noch lernen, damit kompetent umzugehen...

Was der Code macht war doch klar und trivial zu ersehen
aber ohne Erfahrung mit TANDY Systemen aus den 90ern bringt mir das 
wissen nix

Aber hier waren ja zum Glück ein paar alte Hasen die gleich wussten was 
der Wert 0x21 an der Speicherstelle 0xF000:0xC000 bedeutet
und die google Treffer wurden auch erst konkreter als das TANDY 
Schlüsselwort dazu gekommen ist

von c-hater (Gast)


Lesenswert?

cppbert3 schrieb:

> Aber hier waren ja zum Glück ein paar alte Hasen die gleich wussten was
> der Wert 0x21 an der Speicherstelle 0xF000:0xC000 bedeutet
> und die google Treffer wurden auch erst konkreter als das TANDY
> Schlüsselwort dazu gekommen ist

Schonmal was von der RBIL gehört? Wenn man mit uralter PC-Scheisse 
hantiert, ist das Pflichtlektüre.

Beitrag #6767796 wurde vom Autor gelöscht.
von cppbert3 (Gast)


Lesenswert?

c-hater schrieb:
> Schonmal was von der RBIL gehört? Wenn man mit uralter PC-Scheisse
> hantiert, ist das Pflichtlektüre.

Klar kenne ich die - bestimmt schon über 20 Jahre

aber bisher habe ich die nur für ganz obskure Interrupts gebraucht (IDA 
hat seine eigene Interrupt Infos die im Disassemblat als Kommentare 
eigebaut werden)

Steht da auch die TANDY BIOS Memorybelegung drin? das wäre mir neu

hab auch so gut wie jeden Kompiler/Assembler aus der alten Zeit, weil 
IDA meist den Kompiler erkennt, dann kann ich die alten Libs linken und 
kann mir arbeit sparen,
hab das original Peter Norton Buch, fast alle PC-Interns als PDF

bisher größtes DOS reverse engineering Projekt: 230.000 Zeilen Assembler 
aus IDA in eine binäridentische Exe zurückassembliert, über 40 Segmente, 
UASM+Watcom Linker+IDA Python Scripts, hat ein paar Wochen Lebenszeit 
verschwendet

aber manches für das ich ewig suchen würde, kommt hier nach 10 Minuten 
als perfekte Antwort, spziell wenn es wie in diesem Fall drumherum voll 
ist mit selbstmodifizierendem Code ist es nicht immer leicht die Antwort 
in einer Referenz zu finden

von c-hater (Gast)


Lesenswert?

cppbert3 schrieb:

> Klar kenne ich die - bestimmt schon über 20 Jahre

Offensichtlich niemals richtig gelesen. Die enthält nämlich (auch wenn 
der Name das nicht vermuten läßt), durchaus sehr viel mehr als nur 
Interrupts.

> Steht da auch die TANDY BIOS Memorybelegung drin? das wäre mir neu

Naja, wie gesagt: du hast das ganz offensichtlich niemals auch nur das 
Inhaltsverzeichnis auch nur überflogen. Sonst wüßtest du, dass da mehr 
drin ist als nur die Interrupts.

von cppbert3 (Gast)


Lesenswert?

c-hater schrieb:
>> Steht da auch die TANDY BIOS Memorybelegung drin? das wäre mir neu
>
> Naja, wie gesagt: du hast das ganz offensichtlich niemals auch nur das
> Inhaltsverzeichnis auch nur überflogen. Sonst wüßtest du, dass da mehr
> drin ist als nur die Interrupts.

zeig mir die Stelle: http://www.ctyme.com/rbrown.htm
oder nutze eine Variante deiner Wahl, sollte dir ja leicht fallen, oder?

von cppbert3 (Gast)


Lesenswert?

habs gefunden!

Danke für den Tip

MEM F000h:C000h - Tandy ROM BIOS ID BYTE

https://github.com/cirosantilli/ralf-brown-interrupt-list/blob/master/inter61c/MEMORY.LST

Zeile 2686

von Thomas Z. (usbman)


Lesenswert?

aus memory.lst:
1
----------MF000C000--------------------------
2
MEM F000h:C000h - Tandy ROM BIOS ID BYTE
3
Size:  BYTE
4
Note:  If the BYTE at this location is equal to 21h, some Microsoft software
5
    assumes this is a Tandy machine, and for example trusts the bits 1-0
6
    at 0040h:00B5h.
7
SeeAlso: MEM 0040h:00B5h"Tandy",INT 15/AH=C0h

wenn schon RBIL dann das Original und nicht WWebsites die die Hälfte 
nicht korrekt konvertiert haben

ups zu spät

: Bearbeitet durch User
von cppbert3 (Gast)


Lesenswert?

Thomas Z. schrieb:
> wenn schon RBIL dann das Original und nicht WWebsites die die Hälfte
> nicht korrekt konvertiert haben
> ups zu spät

in der komischen HTML Variante die ich habe fehlt die Info, im Original 
ists drin :/

gut das ich das jetzt auch mitbekommen hab weil im Folgecode sind noch 
ein Haufen so alte Adressen drin

von c-hater (Gast)


Lesenswert?

cppbert3 schrieb:

> gut das ich das jetzt auch mitbekommen hab weil im Folgecode sind noch
> ein Haufen so alte Adressen drin

Mal wieder ein schönes Beispiel dafür, dass das biblischen Bild vom 
Verschenken von Fischen vs. der Vermittlung der Kompetenz zum Fischen 
immer noch zutreffend ist. Nach 2000 Jahren. Manche Weisheiten veralten 
einfach nicht.

Übrigens danke für den Link zum aktuellen Ablageort der RBIL (möge sie 
nicht sterben!). Habe gerade meine lokale Kopie damit abgeglichen und 41 
Erweiterungen und 8 Korrekturen(?) festgestellt. Ich bin wirklich 
überrascht, dass es offensichtlich immer noch einen Haufen Anlässe gibt, 
sich mit diesem uralten Kram zu beschäftigen.

Ich selber habe da vor ca. 10 Jahren das letzte Mal reingeschaut. Weiss 
garnicht mehr, wo sie damals gehostet wurde.

Was ich aber noch weiss: Meine erste Version der RBIL habe ich noch per 
Mailbox bezogen. Nix Internet...

von cppbert (Gast)


Lesenswert?

c-hater schrieb:
> Übrigens danke für den Link zum aktuellen Ablageort der RBIL (möge sie
> nicht sterben!). Habe gerade meine lokale Kopie damit abgeglichen und 41
> Erweiterungen und 8 Korrekturen(?) festgestellt.

ich glaube das ist offizielle Ablageort:
http://www.cs.cmu.edu/~ralf/files.html

die könnte/sollte der Github-Version entsprechen (ich nutze jetzt die 
~ralf-Variante - aber vergleichen sollte es wohl auch)

> Was ich aber noch weiss: Meine erste Version der RBIL habe ich noch per
> Mailbox bezogen. Nix Internet...

ich glaub ich auch, bestimmt mit einem 14.4k bau modem :/

von Georg (Gast)


Lesenswert?

cppbert schrieb:
> ich glaub ich auch, bestimmt mit einem 14.4k bau modem

Na gegenüber einem Akustikkoppler war das doch ein gigantischer 
Fortschritt. Und so zuverlässig...

Und Einmachgummis zum Festhalten brauchte man auch nicht mehr.

Georg

von cppbert (Gast)


Lesenswert?

cppbert schrieb:
> die könnte/sollte der Github-Version entsprechen

die github Version entspricht exakt dem http://www.cs.cmu.edu/~ralf 
Stand

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.