EMS 3.2 unter DOS (<= 286)

[Jackintosh]

Da ich wegen 512KB SRAM (viewtopic.php?f=2&t=13677) nicht eine PCB route, soll da noch mehr drauf. Für 68K habe ich einen SDR-SDRAM Controller in VHDL geschrieben. Tut alles seit diesem Frühjahr. Nun dachte ich mir, daß ich die Schaltung auf 8bit Datenbus abgespeckt an 8bit ISA adaptieren könnte und dem System 32MB EMS unterjubel nach LIM 3.2. LIM 4.0 verlagert zuviel in HW, da reicht mir auch das größte CPLD der Familie sicher nicht aus.
Ein EMS 3.2 Treiber sieht jetzt nicht sonderlich komplex aus. So wie ich das sehe, muss er primär dafür sorgen, dass die richtigen 16KB Seiten in den 64KB EMS Frame eingeblendet werden. Eine Speicherverwaltung à la malloc()/free() gibt es hier wohl nicht. Die Applikation muss eine Anzahl 16KB Seiten anfordern und dann selbst verwalten. Der gemeinsame Nenner zwischen Appl. und EMS-Manager sind dann die EMS-Handles.

Hierzu Fragen:

• bei LIM 3.2 muss der EMS Rahmen aus einem 64KB Block am Stück bestehen. Muss dieser Rahmen an einer glatt durch 64K teilbaren Adresse (D000h, E000h,...) liegen oder wie groß ist die kleinste Granularität, die ich unterstützen muss?
• wenn die Applikation über INT 67h Funktion 43h Seiten allokiert, dann müssen diese nicht en bloc im EMS (also nicht dem 64KB EMS Frame) liegen, sondern dürfen fragmentiert sein?
• ich kenne bisher nur das limems40.txt Dokument. Somit weiss ich nicht, was ggü. 3.2 hinzugekommen ist. Gibt es irgendwo im Netz eine 3.2 Doku? Ich hab bisher erfolglos rumgesucht.
• das Einblenden der 16KB Seiten in den EMS-Frame ist hardwareabhängig, d.h. unterschiedliche EMS Karten nutzen unterschiedliche Ports und Mechanismen, um Seiten einzublenden. Dann gibt es aber auch generische Abschnitte (Handleverwaltung), die wohl identisch sind.
  Gibt es generische EMS-Manager, die den HW-abhängigen Teil an einen nachgelagerten Treiber auslagern? So eine Art DaisyChain im INT 67h. Was der erste in der Kette nicht kann, gibt er an den nächsten (so vorhanden) weiter?

Nebenbei mal eine "Notationsfrage": ich komme aus der Atari ST Welt. TOS (bzw. der GEMDOS Teil) wurde von DR entwickelt und hat - wie MS-DOS auch - CP/M Erbgut in sich.
Unter TOS haben alle OS Funktionen klar definierte Namen, an die sich alle (Foren, Doku, Libs) halten z.B. Ptermres() = Process terminate and stay resident.
Ich habe hier ein M&T Buch über DOS und da sind immer nur die Funktionscodes für INT 21h genannt. Gibt es solche eindeutigen Namen im DOS Sprachgebrauch nicht?

[mkarcher]

Ein EMS 3.2 Treiber sieht jetzt nicht sonderlich komplex aus. So wie ich das sehe, muss er primär dafür sorgen, dass die richtigen 16KB Seiten in den 64KB EMS Frame eingeblendet werden. Eine Speicherverwaltung à la malloc()/free() gibt es hier wohl nicht. Die Applikation muss eine Anzahl 16KB Seiten anfordern und dann selbst verwalten. Der gemeinsame Nenner zwischen Appl. und EMS-Manager sind dann die EMS-Handles.

Ja, sonderlich kompliziert ist der nicht. Was Du bauen willst, hast Lo-Tech (aber wohl nur mit 2MB) schon gebaut, und die haben den Quellcode für ihren Treiber veröffentlicht. In der Lizenz ist eine no-compete-Klausel drin, Du darfst den Treiber also nicht für ein kommerzielles Produkt verwenden, was Konkurrenz zu den Lo-Tech produkten macht. Im Hobby-Bereich ist das unkritisch. Ich habe auf Basis von deren Treiber einen Treiber für Mainbaords mit TOPCAT-Chipsätzen gebaut, siehe https://github.com/karcherm/topemm/ , der bis zu 32MB EMS unterstützt, ohne dabei unerträglich viel RAM für die Verwaltung zu belegen, oder langsame Algorithmen für die Verwaltung zu brauchen. Den kannst Du als Basis für einen eigenen Treiber nehmen.

bei LIM 3.2 muss der EMS Rahmen aus einem 64KB Block am Stück bestehen. Muss dieser Rahmen an einer glatt durch 64K teilbaren Adresse (D000h, E000h,...) liegen oder wie groß ist die kleinste Granularität, die ich unterstützen muss?

Die Frage ist falschrum gestellt. Als Hardware-Designer hast Du die volle Freiheit, was Du unterstützen willst. Dann muss Dein Treiber das, was Deine Hardware halt bietet an die Software weitermelden, die die EMS-API aufruft. Du musst nicht eine Granulatität unterstützen, aber du darfst beliebige Segmentadressen (auch 1234h) an EMS-nutzende Programme melden - Hauptsache Deine Hardware schafft das.

Praktisch liegen EMS-Pageframes von Hardware-EMS immer auf 16K-alignten Adressen, bei einfach Karten gelegentlich sogar auf 64K-alignten Adressen, weil das das Decoding einfacher macht.

Ein Beispiel für EMS-Treiber, die "total wilde" Pageframe-Adressen melden sind Software-EMS-Emulatoren, die 64KB konventionellen Speicher reservieren, und dann bei jeder Mapping-Operation physische Kopien des Speicherinhalts anfertigen. EMM286 macht das zum Beispiel, um XMS-Speicher an EMS-Programme zur Verfügung zu stellen. Dass dabei die Performance des "mappings" saumäßig schlecht ist, ist offensichtlich, aber die Norm lässt solche "Limulatoren" explizit zu, und schneller als Swapping auf eine Festplatte ist es allemal.

wenn die Applikation über INT 67h Funktion 43h Seiten allokiert, dann müssen diese nicht en bloc im EMS (also nicht dem 64KB EMS Frame) liegen, sondern dürfen fragmentiert sein?

Genau. Die Applikation merkt ja gar nicht, ob die Seiten kontinuierlich im EMS liegen, oder wild durchgewürfelt. Du musst sogar fragmentieren können, da es unter EMS meines Wissens nach keine Unterscheidung zwischen "insgesamt freien Seiten" und "zusammenhängenden freien Seiten" gibt. Da eh jede Seite für sich gemappt wird, ist die einzige Folge der Fragmentierbarkeit einzelner Handles, dass der Verwaltungsaufwand steigt.

ich kenne bisher nur das limems40.txt Dokument. Somit weiss ich nicht, was ggü. 3.2 hinzugekommen ist. Gibt es irgendwo im Netz eine 3.2 Doku? Ich hab bisher erfolglos rumgesucht.

Wenn Du in Ralph Brown's Interrupt-Liste guckst, dann steht bei den 3.2-Funktionen im Titel nur "LIM EMS", bei den 4.0-Funktionen dagen "LIM EMS 4.0". Solange Du nur ein 64K-Pageframe anbietest, und keine Spezialmappings für DMA hast, reicht die 3.2-Spezifikation. Das sind die Funktionen 40h bis 4Eh.

das Einblenden der 16KB Seiten in den EMS-Frame ist hardwareabhängig, d.h. unterschiedliche EMS Karten nutzen unterschiedliche Ports und Mechanismen, um Seiten einzublenden. Dann gibt es aber auch generische Abschnitte (Handleverwaltung), die wohl identisch sind.

Gibt es generische EMS-Manager, die den HW-abhängigen Teil an einen nachgelagerten Treiber auslagern? So eine Art DaisyChain im INT 67h. Was der erste in der Kette nicht kann, gibt er an den nächsten (so vorhanden) weiter?

Das ist mir leider nicht bekannt.

Nebenbei mal eine "Notationsfrage": ich komme aus der Atari ST Welt. TOS (bzw. der GEMDOS Teil) wurde von DR entwickelt und hat - wie MS-DOS auch - CP/M Erbgut in sich.
Unter TOS haben alle OS Funktionen klar definierte Namen, an die sich alle (Foren, Doku, Libs) halten z.B. Ptermres() = Process terminate and stay resident.
Ich habe hier ein M&T Buch über DOS und da sind immer nur die Funktionscodes für INT 21h genannt. Gibt es solche eindeutigen Namen im DOS Sprachgebrauch nicht?

Kurznamen wie "Ptermres" gibt es nicht. Bei den meisten Funktionen existieren Langnamen, die sich eingebürgert haben, die wahrscheinlich auch in der offiziellen DOS-API-Dokumentation von Microsoft enthalten sind. Für die undokumentierten Funktionen ist das bei der Benennung schon eher Wildwuchs. Daher hat es sich tatsächlich eingebürgert, DOS-Funktionen über ihre Nummer zu benennen, wenn es kurz und eindeutig sein soll.

[Jackintosh]

Ja, sonderlich kompliziert ist der nicht. Was Du bauen willst, hast Lo-Tech (aber wohl nur mit 2MB) schon gebaut,

Ja, aber bei 15,-€/MByte SRAM...

Praktisch liegen EMS-Pageframes von Hardware-EMS immer auf 16K-alignten Adressen

Habe ich vorhin beim Intel-Above Board (von dem ich sogar ein hier habe) gesehen. Somit werde ich im CPLD für jede der vier Pages 6 Bit vorsehen (A14..A19) und es auch zulassen, dass der EMS-Frame bei A000h beginnen darf: https://youtu.be/Xcc_D7q9bQs

Du musst sogar fragmentieren können, da es unter EMS meines Wissens nach keine Unterscheidung zwischen "insgesamt freien Seiten" und "zusammenhängenden freien Seiten" gibt. Da eh jede Seite für sich gemappt wird, ist die einzige Folge der Fragmentierbarkeit einzelner Handles, dass der Verwaltungsaufwand steigt.

Gerade mal überschlagen: wenn ich 2048 Pages à 16KByte unterstütze und 256 Handles zulasse und für jedes Handle ein ArrayOfBit[0..2047] - gleich 256Byte - für die Belegungstabelle zulasse, komme ich auf 256 Handles x 256Byte = 64KByte.
Oder ich nehme ein ArrayOfByte[0..2047] und trage die HandleNummer als item in das Array ein.
Die Frage ist: was ist wirtschaftlicher bezogen Rechenzeit für Suchen bzw. RAM Verbrauch? Wobei ich meine EMS-Handler internen Datenstrukturen ja selbst ins EMS legen kann. Ein-/Ausblenden der Seiten ist ja recht fix erledigt.
Momentan tendiere ich zum ArrayOfBit[].
Weniger als 256 Handles sind wohl erlaubt. Aber welche Maximalzahl an Handles benötigt eine Applikation wirklich?
Bissl Stochern im Nebel.

(...) und keine Spezialmappings für DMA hast(...)

Dann müsste meine ISA Karte DMA unterstützen? Was ich eigentlich nicht vor habe, da Komplexität im CPLD steigt und SDRAM schon viel wegfrisst.

BTW: was passiert eigentlich, wenn man mehrere EMS Karten unterschiedlicher Hersteller gleichzeitig in einem PC betreiben will? Ich nehme mal an, daß das nicht geht, da DaisyChaining im INT 67h wohl nicht vorgesehen ist.

[mkarcher]

Praktisch liegen EMS-Pageframes von Hardware-EMS immer auf 16K-alignten Adressen

Habe ich vorhin beim Intel-Above Board (von dem ich sogar ein hier habe) gesehen. Somit werde ich im CPLD für jede der vier Pages 6 Bit vorsehen (A14..A19) und es auch zulassen, dass der EMS-Frame bei A000h beginnen darf: https://youtu.be/Xcc_D7q9bQs

Du könntest auch den gesamten Bereich von A000 bis EFFF auf beliebige Seiten im RAM mappen lassen, und einen EMS-4.0-Treiber (da habe ich aber keine Vorlage zur Hand) bauen. EMS-4.0-Seiten in UMBs umwandeln ist kein Problem, da gibt es Treiber für.

Gerade mal überschlagen: wenn ich 2048 Pages à 16KByte unterstütze und 256 Handles zulasse und für jedes Handle ein ArrayOfBit[0..2047] - gleich 256Byte - für die Belegungstabelle zulasse, komme ich auf 256 Handles x 256Byte = 64KByte.
Oder ich nehme ein ArrayOfByte[0..2047] und trage die HandleNummer als item in das Array ein.
Die Frage ist: was ist wirtschaftlicher bezogen Rechenzeit für Suchen bzw. RAM Verbrauch?

Du kannst ja schauen, wie das in topemm gelöst ist. Die wichtigste Erkenntnis ist, dass es zwar 2048 Pages und einige Handles (10 sollten genug sein. Die meisten Programme brauchen genau eines, also hast Du mit 10 Handles genug für den Plattencache, EMS-Puffer für einen Netzwerk-Stack, EMS-Puffer für ein Hotkey-aktiviertes TSR, dass den Bildschirmspeicherinhalt des unterbrochenem Programm im EMS ablegt, und EMS für das aktive Programm. Und 6 weitere Handles, für die ich schon keine Idee mehr habe, wofür sie genutzt werden könnten...) gibt, aber dennoch nur 2048 Pages insgesamt. In dem "Array Of Byte"-Vorschlag hast Du diese Erkenntnis schon umgesetzt, wogegen im ArrayOfArrayOfBit das keine Rolle spielt.

Der Ansatz in TOPEMM ist ein Array von Words zu haben, in denen die Pagrnummern stehen. Und zwar vorne im Array die belegten Pages, und hinten im Array die freien Pages. Für den Fall, dass die Anzahl der Pages bekannt ist, braucht das Array nur so groß zu sein, wie Du Pages hast. Die belegten Pages stehen in einer solchen Reihenfolge im Array, dass die Pages für einen Handle am Stück stehen. Pro Handle merkst Du Dir nur den Startindex in diesem Array und die Anzahl der Pages. Außerdem merkst Du die den Punkt, ab wo die freien Pages beginnen. Damit sind die häufigsten Operationen sehr schnell:

• Anlegen eines neuen Handles: Einfach den aktuellen "ab hier frei"-Startpunkt in die Handle-Liste eintragen, und ihn entsprechend weiterschieben. Damit sind so viele ehemals freie Pages belegt, wie das Programm angefordert hat.
• Freigeben des als letztes angelegten Handles: Den "ab hier frei"-Starpunkt wieder zurückschieben.
• Resize des als letzes angelegten Handles: Auch hier einfach nur den Splitpoint verschieben.
• Übersetzen einer "logischen Page-Nummer" (Handle-Nummer + Index): Startpunkt des Handles auslesen, Index addieren, Nummer der tatsächlichen Page finden.

Folgende Operationen sind dagegen aufwändiger

• Freigeben eines Handles, der nicht am Ende liegt: Pagenummern des freigegeben Handles in einen Temporärpuffer schieben, im Array alle dahinter befindlichen belegten Seitennummern nach vorne schieben, und den Inhalt des Temporärpuffers in den freigewordenen Platz schieben. Alternativ kann man das "one-page-at-a-time" rotieren, was aufwändig ist, aber keinen Temporärpuffer braucht. Oder irgendeinen Kompromiss wie 16-pages-on-a-time, und davon ausgehen, dass für 16 Pagenummern Platz auf dem Stack des Aufrufers ist. Danach Anpassung der Start-Indizes für alle Handles, die weiter hinten liegen.
• Verkleinern eines Handles, der nicht am Ende liegt: Wie freigeben, nur nicht alle Pages von dem Handle in den Frei-Bereich verschieben.
• Vergrößern eines Handles, der nicht am Ende liegt: Wie freigeben, nur dass andersherum rotiert werden muss.

Diese Operationen sollten aber selten genug sein, denn alle Handles außer dem zuletzt reservierten gehören meistens zu TSRs, die sich gar nicht damit befassen wollen, dass das EMS alle sein kann, während sie etwas im Hintergrund tun, und daher die Handles einmal holen, und nie resizen.

(...) und keine Spezialmappings für DMA hast(...)

Dann müsste meine ISA Karte DMA unterstützen? Was ich eigentlich nicht vor habe, da Komplexität im CPLD steigt und SDRAM schon viel wegfrisst.

"Spezialmappings für DMA" bedeutet, dass die Karte ein paar zusätzliche Mappings (also je 4 Register bei einem 64KB-Pageframe) hat, und für den Fall, dass auf dem ISA-Bus DACK für einen bestimmten DMA-Kanal (oder eine programmierbare Maske von DMA-Kanälen) aktiv ist (bitte selbst nachschlagen, ob DACK active low oder active high ist...), das entsprechende Extra-Mapping verwendet, und nicht das, was derzeit per "map page" gesetzt wurde. Die Idee davon ist, dass Ein Disk-Cache im Hintergrund Daten aus seinem EMS-Puffer auf eine Diskette (DMA2) oder eine XT-Festplatte (DMA3) schreiben kann, während im Vordergrund ein EMS-verwendes Programm seine Applikationsseiten gemappt hat. Ebenso könnte damit digitalisierter Sound aus einem EMS-Puffer abgespielt werden, ohne dass dafür die Seiten im normalen Page-Frame permanent sichtbar sein müssen.

Man kann sich hier den Einstz: "Ein Mapping pro DMA-Kanal für maximale Entkopplung" vorstellen, oder "Ein Mapping pro Task in einem Multitasking-System; DMA-Kanäle werden an Tasks vergeben", wobei das dann aber auch in den Bereich des "schnellen Task-Switch" kommt, wo alternative Mapping-Sets mit einem einzelnen Port-Befehl umgeschaltet werden können sollen.

Um ehrlich zu sein: Ich habe keine Ahnung, ob irgendein Betriebssystem oder Cache dieses Feature tatsächlich nutzt, aber es ist im CPLD vermutlich eher leicht zu implementieren, und währe etwas, worauf man technisch stolz sein kann.

BTW: was passiert eigentlich, wenn man mehrere EMS Karten unterschiedlicher Hersteller gleichzeitig in einem PC betreiben will? Ich nehme mal an, daß das nicht geht, da DaisyChaining im INT 67h wohl nicht vorgesehen ist.

Es gibt einen de-facto-Standard für alte EMS-3.2-Karten in XTs. Man verwendet 4 aufeinanderfolgende I/O-Ports, in denen das oberste Bit ein "page enable"-Bit ist, und die anderen 7 Bit die physische Nummer der Page angeben, die auf dem Index im Pageframe eingeblendet werden soll, der zu dem I/O-Port gehört. Damit können maximal 128 Pages unterstützt werden, was am Ende 2MB ergibt - eine sehr typische Kapazität von historischen EMS-Karten. Wenn man mehrere Karten hat, die alle dieses Schema verwenden, dann gibt es Treiber, die mehrere Karten gleichzeitg unterstützen, und Pages immer nur auf einer der Karten einschalten, so dass es wie eine virtuell größere Karte wirkt. Das ergänzt sich gut damit, dass 4MB und 8MB-Karten häufig wie 2 oder 4 von den 2MB-Karten auch hardwareseitig implementiert sind.

Sobald Du aber wirklich herstellerspezifische Treiber brauchst, um auf eine EMS-Karte zuzugreifen, kannst Du nur eine auf einmal im Computer haben. So viel Platz hat man ja im Upper Memory auch nicht, dass es allgemein sinnvoll erscheint, mehrere Page-Frames dort einzublenden.

[Jackintosh]

Wegen EMS 4.0: da lese ich viel, was ich momentan nicht verstehe. Mir schwebt erstmal ein KISS Ansatz vor. Zumal ich den 68k Bus auf ISA umsetzen muss. Und für jemanden, der 68k kennt, ist ISA schon gruselig.
Außerdem: Featuritis killt jedes Projekt.

Frage zu EMS 3.2 Funktionen 47h/48h:
ist mit dem Mapping die Zuordnung logischer zu physikalischer Page gemeint? Bedeutet dies, daß ich für jedes Handle die vier 11Bit Register im RAM speichere bzw. in die Register zurückschreibe? Und ich habe eine "Sicherungstiefe" von einem Mappingsatz? Und nicht eine Art Stack für solche Mappingsätze?

Sorry... aber den Absatz über DMA habe ich wohl nicht verstanden!
Ich stelle mir die Register im CPLD wie folgt vor:

• 1x Pageregister (6bit): dies sind die obersten 6 Bit des Adressbusses. In diesem Register wird vermerkt, an welcher 16KB alignten Adresse im 1MB Adressraum der 64KB EMS-Frame eingeblendet wird. An Zugriffen auf diese Adresse (+ den 64K Adressraum hinter dieser Adresse) erkennt das CPLD, daß es Zugriff auf eine Page im EMS erlauben muss. Und welche das ist, steht hier:
• 4x EMS-Pageregister-intern (11bit): wird zur internen Verwaltung genutzt. Hier steht welche der 2048 EMS-Pages in die zum jeweiligen Index [0..3] gehörende Page im 1MB Adressraum eingeblendet wird. Um 32M zu adressieren, benötige ich eine 25Bit Adresse: 11Bit aus diesem Register sind A[24..14] und vom ISA-Adressbus kommen A[13..0].

Der Ansatz in TOPEMM ist ein Array von Words zu haben, in denen die Pagrnummern stehen. Und zwar vorne im Array die belegten Pages, und hinten im Array die freien Pages.

Also bei meinem System wäre das ein Array Of Word[0..2047]?
Angenommen ein Programm fordert mehrere Handles an und gibt sie zur Laufzeit auch wieder an den EMM zurück - und das mehrfach, dann müsstest Du die Liste zur Laufzeit regelmäßig umsortieren.

Ich denke, es läuft auf den übliche trade-time-for-space Ansatz hinaus.

Die Idee davon ist, dass Ein Disk-Cache im Hintergrund Daten aus seinem EMS-Puffer auf eine Diskette (DMA2) oder eine XT-Festplatte (DMA3) schreiben kann, während im Vordergrund ein EMS-verwendes Programm seine Applikationsseiten gemappt hat. Ebenso könnte damit digitalisierter Sound aus einem EMS-Puffer abgespielt werden, ohne dass dafür die Seiten im normalen Page-Frame permanent sichtbar sein müssen.

Damit auf EMS (per PIO oder DMA) zugegriffen werden kann, muß zwingend die jeweilige Page eingeblendet sein, d.h. das jeweilige 11bit Register muss vom EMM korrekt gesetzt worden sein.
Den einzigen Ansatz, den ich habe, um obiges zu verstehen, ist:
für jeden DMA Kanal (bei 8bit ISA sind das drei Stück) gibt es vier weitere 11bit Register (somit 3 x 4 x 11Bit = 132Bit). In diesen steht das (logische-zu-physikalische-Page) Mapping drin, falls der jeweilige DMA Kanal aktiv ist. Sobald alle DMA Kanäle inaktiv sind, wird auf die vier 11Bit Register umgeschaltet, die ich weiter oben erwähnte. Das wären dann PIO-Register im Unterschied zu den 3 x 4 11Bit DMA-Registern.
Wenn dem so wäre, müsste das INT 67h API aber dies auch hergeben (d.h. Setzen der vier 11Bit DMA Register) und das sehe ich zumindest für LIM 3.2 nicht.

Ich werde erstmal das 8bit SDRAM und das Latch in Eagle anlegen und mit dem Stromlaufplan beginnen.

Was mir bei meiner Recherche noch aufgefallen ist: QEMM erlaubt in späteren Versionen bis zu 256MB EMS/XMS lt. englischem Wikipedia. Wenn das nun > 64MB EMS sein dürfen, danns stellt sich mir die Frage, wie das LIM 4.0 konform ist? Oder fragen Applikationen u.U. ab, ob solch ein QEMM installiert ist und nutzen dann erweiterte Möglichkeiten desselben?

Was passiert eigentlich bei 80x86, wenn die CPU einen R/W Zugriff auf eine I/O oder Memory Adresse tätigt, an der nichts vorhanden ist. Also Zugriff ins Nirwana. In 68k Systemen ist es i.d.R. so, daß ein externener Watchdog dann die /BERR Leitung zur CPU aktiviert und diese dann den Handler für eine BusException ausführt d.h. ganz böse Sache!

[mkarcher]

Wegen EMS 4.0: da lese ich viel, was ich momentan nicht verstehe. Mir schwebt erstmal ein KISS Ansatz vor. Zumal ich den 68k Bus auf ISA umsetzen muss. Und für jemanden, der 68k kennt, ist ISA schon gruselig.
Außerdem: Featuritis killt jedes Projekt.

Unter diesem Aspekt: Bleibe bei EMS 3.2. EMS 4.0 ist interessant für Multitasking-Lösungen, insbesonder DesqView und Windows 3.0 im Real Mode, und zumindest bei Windows 3.0 vor allem dann, wenn die EMS-Karte auch einen großen Teil des konventionellen Speichers zur Verfügung stellt. Für den normalen DOS-Use-Case werden die EMS-4.0-Funktionen eh nicht genutzt.

Frage zu EMS 3.2 Funktionen 47h/48h:
ist mit dem Mapping die Zuordnung logischer zu physikalischer Page gemeint? Bedeutet dies, daß ich für jedes Handle die vier 11Bit Register im RAM speichere bzw. in die Register zurückschreibe? Und ich habe eine "Sicherungstiefe" von einem Mappingsatz? Und nicht eine Art Stack für solche Mappingsätze?

Es wird genau diese Mapping-Information gespeichert, die Du beschreibst. Du hast eine Sicherungstiefe von einem Mappingsatz pro Handle. Dabei hat die Sicherung, die zu einem Handle hinterlegt wird nicht unbedingt etwas mit den EMS-Seiten, die diesem Handle zugeordnet sind, zu tun. Im Gegenteil: Die Idee ist: Du hast ein TSR, was im Hintergrund EMS nutzen will. Daher hat es bei der Initialisierung einen EMS-Handle mit zugehörigen Seiten für das TSR reserviert. Zusammen mit diesem Handle erhält das Programm im EMS-Treiber auch einen Speicherplatz für so eine Sicherung des aktuellen Mappings. Wenn dann später das Programm auf seine Pages zugreifen will, lässt es den EMS-Treiber den aktuellen EMS-Zustand (der Seiten eines oder mehrere andere Handles enthalten kann) in den Speicherplatz sichern, der zum EMS-Handle des TSR gehört. Dann mappt es seine Seiten, erledigt seine Arbeit, und lässt den EMS-Treiber am Ende die Sicherung zurückspielen.

Sorry... aber den Absatz über DMA habe ich wohl nicht verstanden!

Doch, hast Du. Du beschreibst die Hardware unten ziemlich richtig.

Ich stelle mir die Register im CPLD wie folgt vor:

• 1x Pageregister (6bit): dies sind die obersten 6 Bit des Adressbusses. In diesem Register wird vermerkt, an welcher 16KB alignten Adresse im 1MB Adressraum der 64KB EMS-Frame eingeblendet wird. An Zugriffen auf diese Adresse (+ den 64K Adressraum hinter dieser Adresse) erkennt das CPLD, daß es Zugriff auf eine Page im EMS erlauben muss. Und welche das ist, steht hier:
• 4x EMS-Pageregister-intern (11bit): wird zur internen Verwaltung genutzt. Hier steht welche der 2048 EMS-Pages in die zum jeweiligen Index [0..3] gehörende Page im 1MB Adressraum eingeblendet wird. Um 32M zu adressieren, benötige ich eine 25Bit Adresse: 11Bit aus diesem Register sind A[24..14] und vom ISA-Adressbus kommen A[13..0].

Genau. Für eine Implementation des EMS-3.2-Standards ist das exakt das, was Du brauchst.

Also bei meinem System wäre das ein Array Of Word[0..2047]?
Angenommen ein Programm fordert mehrere Handles an und gibt sie zur Laufzeit auch wieder an den EMM zurück - und das mehrfach, dann müsstest Du die Liste zur Laufzeit regelmäßig umsortieren.

Genau, Du musst dann umsortieren, wenn Du nicht Stack-artig arbeitest. Das Zurückgeben des letzten Handles verursacht keine Umsortierarbeit. Und danach verursacht das Zurückgeben des neuen letzten Handles (ehemals vorletzten Handles) ebenfalls keine Sortierarbeit. Arbeit hast Du nur, wenn Du in einem weiter vorne im Array liegenden Handle die Anzahl der Pages ändern willst (was auch das Freigeben betrifft: Da änderst Du auf null).

Die Idee davon ist, dass Ein Disk-Cache im Hintergrund Daten aus seinem EMS-Puffer auf eine Diskette (DMA2) oder eine XT-Festplatte (DMA3) schreiben kann, während im Vordergrund ein EMS-verwendes Programm seine Applikationsseiten gemappt hat. Ebenso könnte damit digitalisierter Sound aus einem EMS-Puffer abgespielt werden, ohne dass dafür die Seiten im normalen Page-Frame permanent sichtbar sein müssen.

Damit auf EMS (per PIO oder DMA) zugegriffen werden kann, muß zwingend die jeweilige Page eingeblendet sein, d.h. das jeweilige 11bit Register muss vom EMM korrekt gesetzt worden sein.
Den einzigen Ansatz, den ich habe, um obiges zu verstehen, ist:
für jeden DMA Kanal (bei 8bit ISA sind das drei Stück) gibt es vier weitere 11bit Register (somit 3 x 4 x 11Bit = 132Bit). In diesen steht das (logische-zu-physikalische-Page) Mapping drin, falls der jeweilige DMA Kanal aktiv ist. Sobald alle DMA Kanäle inaktiv sind, wird auf die vier 11Bit Register umgeschaltet, die ich weiter oben erwähnte. Das wären dann PIO-Register im Unterschied zu den 3 x 4 11Bit DMA-Registern.

Wenn dem so wäre, müsste das INT 67h API aber dies auch hergeben (d.h. Setzen der vier 11Bit DMA Register) und das sehe ich zumindest für LIM 3.2 nicht.

Genau, das ist eines der LIM-4.0-Features. Die zuständigen Funktionen sind 5B05 bis 5B08. Die haben zwar ein anderes Modell, nämlich dass Registersets einem oder mehreren Kanälen zugeordnet werden können, aber das kann man in Software problemlos emulieren, wenn die Hardware je ein Set pro fest verdrahtetem Kanal hat. Die Idee hinter der Spezifikation ist wohl, dass man in Hardware weniger Sets haben kann als es DMA-Kanäle gibt, was insbesondere bei 16-Bit-Karten den Aufwand sparen kann.

Was mir bei meiner Recherche noch aufgefallen ist: QEMM erlaubt in späteren Versionen bis zu 256MB EMS/XMS lt. englischem Wikipedia. Wenn das nun > 64MB EMS sein dürfen, danns stellt sich mir die Frage, wie das LIM 4.0 konform ist? Oder fragen Applikationen u.U. ab, ob solch ein QEMM installiert ist und nutzen dann erweiterte Möglichkeiten desselben?

Dass es insgesamt mehr als 65536 pages gibt, muss ja nicht heißen, dass man mehr als 655356 auf einen einzigen Handle allozieren kann. Genauso schadet es auch nicht unbedingt, wenn nur "32MB frei" gemeldet wird, selbst wenn noch 192 MB frei sind. Man kommt also auch schon ohne erweiterte API ohne größere Probleme dazu, dass insgesamt mehr als 32MB angeboten werden. Ob QEMM hier noch spezielle APIs bietet, die den Workaround von mehreren Handles zu jeweils 32MB die einzige Methode ist, um auf so viel Speicher zuzugreifen, kann ich Dir nicht sagen.

Programme, die EMS unterstützen kommen in der Regel aus der 8086-Zeit, und können mit mehr als 32MB sowieso nichts anfangen. In 32MB passt ja drei mal der Inhalt einer typischen XT-Festplatte von 1984 rein. 256MB EMS ist vor allem für Multitasking relevant, und QEMM ist ja auch als Multitasking-Treiber für DesqView gedacht. Für das Herausgeben von EMS an 20 parallele DOS-Boxen machen dann 64MB auch Sinn. Das wären dann etwa 3MB pro DOS-Box, und damit in einem "typischen" Bereich für EMS-Programme.

Was passiert eigentlich bei 80x86, wenn die CPU einen R/W Zugriff auf eine I/O oder Memory Adresse tätigt, an der nichts vorhanden ist. Also Zugriff ins Nirwana. In 68k Systemen ist es i.d.R. so, daß ein externener Watchdog dann die /BERR Leitung zur CPU aktiviert und diese dann den Handler für eine BusException ausführt d.h. ganz böse Sache!

Der ISA-Bus braucht keine aktive Terminierung von Bus-Zyklen. Zu XT-Zeiten wurde davon ausgegangen, dass Zyklen "by default" in der Zeit terminiert werden, die der 8088 braucht (also etwa 3 Prozessortakte). Wenn eine Karte mehr Zeit braucht (z.B. weil die MDA- oder CGA-Karte gerade ihr RAM braucht, um den Bildschirminhalt auszulesen), kann sie durch das low-ziehen von IOCHRDY die automatisiche Terminierung von Zyklen unterdrücken. Dann wartet der Computer, bis IOCHRDY wieder high ist, und terminiert den Buszyklus in dem Takt.

Was beim Verständnis von ISA hilft: Vergiss den Takt! ISA ist als asynchroner Bus gedacht. Die Dauer eine Zyklus ergibt sich daraus, wie lange eines der Zyklus-Signale aktiv ist, also /MEMW-, /MEMR-, /IOW- oder /IOR-Leitung low ist. Die Adressleitungen sind stabil, solange das Zyklus-Signal aktiv ist. Wenn Du es nicht schaffst, einen Zyklus in der Default-Dauer zu terminieren, musst Du rechtzeitig (und das ergibt sich ab der Zeit, wo die Zyklus-Leitung aktiv wird) IOCHRDY low ziehen. Ansonsten hängt das Timing nicht davon ab, wann der Zyklus beginnt. Bei Lese-Zyklen musst Du Daten präsentieren, bis das Zyklus-Signal deaktiviert wird. Der Transfer findet irgendwann zwischen der Minimal-Wartezeit (die müsste ich nachschlagen) und dem Deaktivieren des Zyklus-Signals statt - in dieser Zeit muss die Karte die Lese-Daten stabil treiben. Der Datentransfer findet nicht statt während IOCHRDY den Bus bremst. In einem durch IOCHRDY gebremsten Zyklus findet der Datentransfer zwischen der Freigabe durch das High-nehmen von IOCHRDY (durch die Karte) und dem Deaktivieren von MEMR/IOR (durch den Host statt). Bei Schreibzyklen sind meines Wissens (müsste ich aber noch mal im Detail nachschlagen) die Datenleitungen über den gesamten Zyklus stabil. Wenn die Karte es nicht schafft, die Daten in der Standard-Zykluszeit die Daten zu übernehmen, muss sie IOCHRDY low ziehen.

ISA hat noch eine fiese Falle zu bieten: Bei DMA-Zyklen wird ein normaler Speicher-Zyklus (also mit Adressleitungen und MEMR oder MEMW) auf dem Bus parallel zu IOR oder IOW und DACKx geführt. Bei einem DMA-Schreib-Zyklus (memory-to-IO) werden also gleichzeitig MEMR und IOW getrieben. Die Adressleitungen geben dabei die Speicheradresse an, keine gültige Portadresse, und das, obwohl IOW aktiv ist. Um damit klar zu kommen, gibt es ein weiteres Signal auf dem Bus, nämlich "AEN" (Address Enable). Das hat während DMA-Zyklen einen speziellen Pegel (bitte nachschlagen...), und muss bei der Dekodierung von IO-Adressen mit berücksichtigt werden, sonst kommt es zu unberechtigten Portzugriffen.

Damit zurück zu Deiner Frage: Wenn sich bei einem Schreibzyklus keiner angesprochen fühlt, wird der Zugriff einfach nach "default-Dauer" terminiert, da er auch nicht durch IOCHRDY verlängert wird. Wenn sich bei einem Lesezugriff keiner angesprochen führt, wird der Zyklus ebenfalls nach "default-Dauer" terminiert. Dabei treibt dann aber niemand die Datenleitungen. Klassischerweise wurden PC-Mainboards mit TTL-Chips aufgebaut, und bei denen wirken ungetriebene Eingange wie "high" (aber man darf sich nicht drauf verlassen, dass die Bus-Kapazität den Eingang nicht doch vielleicht noch low zieht), so dass man in der Regel 0FFh liest, wenn keine Karte reagiert. Auf Mainboards mit CMOS-Technik wird die CMOS-Technik normalerweise auf TTL-Pegel dressiert (wie z.B. in der HCT-Reihe), so dass man auch dort einigermaßen zuverlässig 0FFh erhält, wenn keine Karte reagiert.

[Jackintosh]

Unter diesem Aspekt: Bleibe bei EMS 3.2. EMS 4.0 ist interessant für Multitasking-Lösungen, insbesonder DesqView und Windows 3.0 im Real Mode, und zumindest bei Windows 3.0 vor allem dann, wenn die EMS-Karte auch einen großen Teil des konventionellen Speichers zur Verfügung stellt. Für den normalen DOS-Use-Case werden die EMS-4.0-Funktionen eh nicht genutzt.

M.E. ein weiteres Argument: die Karte ist für den 8bit Bus gedacht und 8088/86 und Windows 3.0 im Multitasking... stell ich mir "herausfordernd" für die Geduld vor.
Sollte ich eine 16bit Auflage in Erwägung ziehen, darfst Du mir die Vorzüge von 4.0 und notwendigen HW Erweiterungen detailiert beibringen.
Außerdem habe ich den Refreshzähler für das SDRAM schon aus dem CPLD heraus in ein 74HCT4040 geschoben, da Rechnen (inkrementieren) im CPLD mir einiges an FunctionBlocks wegfrisst.Der Startup-Delay Zähler für das SDRAM ist auch in dem 4040. Die ganzen Voll-,Halbaddierer kosten wohl einiges an Platz. Zudem gehen mir schlichtweg die Pins am CPLD aus.
Außerdem muß noch das UMB-SRAM mit seinen Konfigurationsmöglichkeiten Platz finden.

Der ISA-Bus braucht keine aktive Terminierung von Bus-Zyklen. Zu XT-Zeiten wurde davon ausgegangen, dass Zyklen "by default" in der Zeit terminiert werden, die der 8088 braucht (also etwa 3 Prozessortakte). Wenn eine Karte mehr Zeit braucht (z.B. weil die MDA- oder CGA-Karte gerade ihr RAM braucht, um den Bildschirminhalt auszulesen), kann sie durch das low-ziehen von IOCHRDY die automatisiche Terminierung von Zyklen unterdrücken. Dann wartet der Computer, bis IOCHRDY wieder high ist, und terminiert den Buszyklus in dem Takt.

Also läuft die Terminierung eines Buszyklusses über eine "Eieruhr" und nicht aktiv durch das angesprochene Target? Außer es meldet über /IOCHRDY mehr Zeitbedarf an. Mittels des /0WS Signals kann hingegen ein Zyklusverkürzung vom ISA device bewirkt werden? Ist dies im 0WS Fall für die CPU verpflichtend oder darf sie wiederum 0WS ignorieren und einen Standardzyklus fahren?

Was beim Verständnis von ISA hilft: Vergiss den Takt!

Und genau hier bringen Du und Andreas Stiller mich durcheinander.
Er schreibt in der c't 11/1991 S.336 (c't Kartei Artikel über den AT Bus - Teil 1):
"Eine wichtige Änderung hat sich im Laufe der Zeit jedoch zwischen dem 4,77-MHz-PC und den moderneren ATs ergeben. Während der XT-Bus noch mit Fug und Recht als synchron bezeichnet werden konnte (alle Signale sind in Timing und Phase starr an den Bustakt gekoppelt), weichte diese starre Kopplung allmählich auf und ergab ein Synchron/Asynchron-Kuddelmuddel. Viele Chipsätze haben zwar ihre Signale synchron zum Bustakt spezifiziert, doch jeder etwas anders. IEEE-P996 trägt dieser Tatsache Rechnung und bezeichnet ISA und E-ISA als `grundsätzlich asynchron mit wenigen synchronen Komponenten´.
Die Asynchronität ist für alle jene Karten von elementarer Bedeutung, die ihr Timing in irgendeiner Weise auf den Bustakt beziehen."

Mit E-ISA bezeichnet die c't hier eine erweiterte (16bit) AT-Bus Variante. Dies ist wohl analog zu den Büchern von Ed Solari. Dieses E-ISA ist nicht gleichbedeutend mit EISA. Mit E-ISA wird lt. c't Artikel wohl der ISA Teil von EISA bezeichnet - was immer das auch bedeutet!
Wobei A.Stiller alle drei Begriffe ISA, E-ISA und AT-Bus gebraucht.

Die Adressleitungen sind stabil, solange das Zyklus-Signal aktiv ist.

Wozu dient dann /BALE?

Bei Schreibzyklen sind meines Wissens (müsste ich aber noch mal im Detail nachschlagen) die Datenleitungen über den gesamten Zyklus stabil.

Im zweiten Teil der o.g. c't Kartei sind die Timingdiagramme aufgeführt, aber sieht es nicht so aus, als würde Deine Aussage zutreffen. Aber sie würde aus Sicht des HW-Entwicklers sinnvoll sein. Beim 68k ist das so.

pic07.jpg (38.64 KiB) 7994 mal betrachtet

pic08.jpg (36.09 KiB) 7994 mal betrachtet

Die Schnarchnasen bei der c't haben die Diagramme als JPG auf der c'tROM abgelegt und nicht als GIF. Ich war's nicht!
Die Zahlen geben den zeitl.Absttand in ns an, aber es ist aus dem Text nicht erkennbar, ob es min. oder max. Zeiten sind.

ISA hat noch eine fiese Falle zu bieten: (...)

Ja, über /AEN bin ich auch schon gestolpert. Ich denke ich werde in VHDL MEMR/MEMW/IOR/IOW in einen 4-bit Vektor zusammenfassen und dann nur reagieren wenn exakt ein Bit=GND ist. Das sollte mich von der von Dir genannten Falle hoffentlich retten.

Bei einem DMA-Schreib-Zyklus (memory-to-IO) werden also gleichzeitig MEMR und IOW getrieben.

Sicher, daß Du da nicht ISA-Busmaster Zugriffe meinst, also wenn z.B. ein SCSI Controller selbst Daten ins RAM schaufelt/bzw. heraus?
Ich verstehe das Konzept so, daß mit "DMA" hier ausschließlich der DMA Baustein 8237A gemeint ist, obwohl ein ISA Device auch als DMA-fähiges Gerät auftreten kann. Nur, daß wir dieselbe Sprache sprechen. Sonst bitte korrigieren!

Damit zurück zu Deiner Frage: (...)

Gut, also zur Not lese ich PullUps.

Für das SRAM ist ein 0WS Zyklus wohl möglich, aber für das SDRAM muss ich vermutlich auf den Standardzyklus ausweichen.

Laut den Diagrammen in der c't Kartei wird /AEN bei Busmasterzyklen aktiv (=GND).
Bei DMA IO-to-memory Zyklen wird /MEMW = /IOR = GND. Das Zeitverhalten ändert sich aber ggü. memory-to-IO.
Aber da schaue ich frühestens rein, falls ich eine 16bit Variante plane.

[mkarcher]

Unter diesem Aspekt: Bleibe bei EMS 3.2. EMS 4.0 ist interessant für Multitasking-Lösungen, insbesonder DesqView und Windows 3.0 im Real Mode, und zumindest bei Windows 3.0 vor allem dann, wenn die EMS-Karte auch einen großen Teil des konventionellen Speichers zur Verfügung stellt. Für den normalen DOS-Use-Case werden die EMS-4.0-Funktionen eh nicht genutzt.

M.E. ein weiteres Argument: die Karte ist für den 8bit Bus gedacht und 8088/86 und Windows 3.0 im Multitasking... stell ich mir "herausfordernd" für die Geduld vor.

Auf einem Turbo-XT mit 10MHz sollten notepad, reversi, der Dateimanager und cardfile schon mit erträglicher Performance laufen. Und wenn man dann ein System hat, wo aller Speicher jenseits von 256KB (also die restlichen 384KB der 640KB konventionellem Speicher plus etwa 128KB in den UMBs) bei einem Taskswitch einfach werden umgemappt werden kann, sollte das in der Tat benutzbar sein. Sobald man einen 286 hat, stellt man für Windows am besten die EMS-Karte in die Vitrine, in der coole obsolete Hardware ausgestellt wird, und lässt Windows im Standard-Modus laufen, wo es Extended Memory nutzen kann.

Auch wenn Du mit der Befürchtung, dass Windows auf der Hardware nicht gerade alles mit hoher "Schwuppdizität" (auch so ein c't-Begriff) ausführen wird, sind Turbo-XT-Computer meines Erachtens nach die einzigen, auf denen EMS 4.0 für Windows so richtig Sinn ergibt. Für DOS-Multitasking (DesqView) sind auch 286-Computer noch im Zielraster. Ab dem 386 ist die einfachste Lösung natürlich der Virtual Mode des Prozessors unter Steuerung durch QEMM oder vergleichbar.

Zudem gehen mir schlichtweg die Pins am CPLD aus. Außerdem muß noch das UMB-SRAM mit seinen Konfigurationsmöglichkeiten Platz finden.

Volle Zustimmung. Fang nicht zu groß an. Ich kann Dir noch einen Tipp geben, der die Komplexität im CPLD senken könnte: Statt eines EMS-Basis-Registers und Komparatoren für die 4 Pages, kannst Du auch wie folgt vorgehen: Die Karte muss auf bis zu 20 16K-Bereiche reagieren können (A000-EFFF), und wenn Du Platz hast, schmeißt Du das oberste Bit auf "enable" und die die 5 Bit darunter auf einen 5-zu-32-Dekoder. Die Ausgänge im 8, 9 und F-Bereich ignorierst Du, und mit dem Rest gehst Du auf eine 20-Bit-Maske, die sagt, ob dort UMB liegt, und eine zweite 20-Bit-Maske, die sagt, ob dort EMS liegt. Die Verantwortung, in die EMS-Maske nur 4 Bit zu tun, die in Folge liegen, kannst Du auf die Initialisierungssoftware abdrücken. Das Page-Register wählst Du im EMS-Fall anhand von A14 und A15 aus. Das heißt dass Du bei Page-Frame-Beginn auf C800 dann eben für C800 auf Page Register 2, für CC00 auf Page Register 3, für D000 auf Page Register 0 und für D400 auf Page Register 1 zurückgreifst. Ob das mit den 2 20-Bit-Masken praktikabel ist, oder das viel zu viele Flipflops kostet, musst Du unter Kenntnis Deines CPLD selbst feststellen.

Der ISA-Bus braucht keine aktive Terminierung von Bus-Zyklen. Zu XT-Zeiten wurde davon ausgegangen, dass Zyklen "by default" in der Zeit terminiert werden, die der 8088 braucht (also etwa 3 Prozessortakte). Wenn eine Karte mehr Zeit braucht (z.B. weil die MDA- oder CGA-Karte gerade ihr RAM braucht, um den Bildschirminhalt auszulesen), kann sie durch das low-ziehen von IOCHRDY die automatisiche Terminierung von Zyklen unterdrücken. Dann wartet der Computer, bis IOCHRDY wieder high ist, und terminiert den Buszyklus in dem Takt.

Also läuft die Terminierung eines Buszyklusses über eine "Eieruhr" und nicht aktiv durch das angesprochene Target? Außer es meldet über /IOCHRDY mehr Zeitbedarf an.

Genau so ist es. Der 8088 hat ja einen 4-Takt-Buszyklus. Im ersten Takt gibt er die Adresse aus, spätestens am Ende des zweiten Takts die Daten (bei Schreibzugriffen). Im dritten Takt ist der Bus stabil, und zu Beginn des vierten Takts werden Daten bei Lesezugriffen übernommen. Waitstates werden dadurch erreicht, dass der "dritte Takt" mehrfach wiederholt wird. Die Eieruhr ergibt sich im Original-PC einfach aus diesem Bus-Timing des Prozessors. Neuere Computer versuchen, zumindest bei 8-Bit-Zugriffen, etwa das gleiche Timing zu erreichen.

Mittels des /0WS Signals kann hingegen ein Zyklusverkürzung vom ISA device bewirkt werden? Ist dies im 0WS Fall für die CPU verpflichtend oder darf sie wiederum 0WS ignorieren und einen Standardzyklus fahren?

Es gibt keine Pflicht für das Mainboard, sich zu beeilen. Daher ist es sinnvoll, 0WS als Angebot zu sehen. Du solltest aber wissen, dass der Pin B8 auf dem ISA-Bus erst ab dem AT (mit seinen 16-Bit-Slots) die Funktion 0WS hat. Im Original-PC ist der Pin reserved (was da wirklich drauf liegt, habe ich nicht im Kopf, jedenfalls ist er für den Busbetrieb völlig irrelevant), und im XT (damit meine ich vor allem genau den IBM 5160, nicht alle XT-kompatiblen) ist er in Slot 8 "Card Select". Wenn in allen 8 Slots ISA-Karten stecken, kann die Bus-Last auf den Datenleitungen zu hoch werden. Daher hat Slot 8 im XT einen vom Rest des ISA-Bus getrennten Datenpfad. Um das Mainboard vom Standard-ISA-Datenpfad auf den Slot-8-Datenpfad umzuschalten (ist m.W. nur für Lesezugriffe relevant), muss die Karte in Slot 8 signalisieren, dass sie zuständig ist.

In einem PC/XT braucht man auch kein 0WS-Signal, denn der Standard-ISA-Zyklus bei 4,77MHz ist bereits das schnellste, was der Computer kann.

Fazit: Wenn Du eine PC/XT-Karte, ignoriere Pin B8. Es sei denn, Du willst "Slot-8-kompatibel" sein. Dann implementiere B8 als Output, der bei Lesezugriffen auf die Karte aktiv (ich glaube low) geht. Im Zweifel kannst Du da einen Jumper reinsetzen, der nur für XT-Slot-8 gesetzt wird.

Was beim Verständnis von ISA hilft: Vergiss den Takt!

Und genau hier bringen Du und Andreas Stiller mich durcheinander.
Er schreibt in der c't 11/1991 S.336 (c't Kartei Artikel über den AT Bus - Teil 1):
Eine wichtige Änderung hat sich im Laufe der Zeit jedoch zwischen dem 4,77-MHz-PC und den moderneren ATs ergeben. Während der XT-Bus noch mit Fug und Recht als synchron bezeichnet werden konnte (alle Signale sind in Timing und Phase starr an den Bustakt gekoppelt), weichte diese starre Kopplung allmählich auf und ergab ein Synchron/Asynchron-Kuddelmuddel.

Andreas Stiller hat recht: Die Signale sind im PC/XT taktsynchron. Aber diese Eigenschaft spielt keine Rolle, denn das Timing, wann Du Adressen und Daten auswerten darfst, wird praktisch am einfachsten über die Zyklus-Signale und IOCHRDY definiert. Du musst nichts mit dem Taktsignal synchronisieren, und deshalb macht das in der Praxis auch keiner. Das ist anders als zum Beispiel bei PCI, wo man die Steuerleitungen, die den Zyklus-Typ angeben nur in der Nähe einer Taktflanke auswerten darf, und man daher ohne Taktsynchronisierung keine funktionsfähige Karte bauen kann.

IEEE-P996 trägt dieser Tatsache Rechnung und bezeichnet ISA und E-ISA als `grundsätzlich asynchron mit wenigen synchronen Komponenten´.
Die Asynchronität ist für alle jene Karten von elementarer Bedeutung, die ihr Timing in irgendeiner Weise auf den Bustakt beziehen."

Die "wenigen synchronen Komponenten" sind hier vor allem der Betrieb bei 0WS. Bei 0WS dauert ein Zyklus minimal 2 Zyklen, und der Zeitpunkt, wann die Karte die Daten liefern muss, ist über "Beginn des nächsten Takt nach Aktivierung von 0WS" definiert. Für PC/XT-Karten spielt 0WS keine Rolle, und daher ist dort ein komplett taktfreies Design das einfachste.

Mit E-ISA bezeichnet die c't hier eine erweiterte (16bit) AT-Bus Variante. Dies ist wohl analog zu den Büchern von Ed Solari. Dieses E-ISA ist nicht gleichbedeutend mit EISA. Mit E-ISA wird lt. c't Artikel wohl der ISA Teil von EISA bezeichnet - was immer das auch bedeutet!

EISA (also der 32-Bit-Bus) ist durch das Konsortium ein von Anfang an klar spezifierter Bus gewesen, wogegen der IBM-kompatible "System Bus", der später ISA genannt wurde, als "das 5150-Mainboard macht das so - seht selbst, wie ihr damit klarkommt" designed wurde. Dadurch heißt es, dass erst durch die Normierung von EISA auch eine klare, eindeutige Spezifikation des 8- und 16-Bit-ISA-Bus stattgefunden hat. Das wird der Grund für "ISA ist Teil von EISA" sein.

Die Adressleitungen sind stabil, solange das Zyklus-Signal aktiv ist.

Wozu dient dann /BALE?

IBM hatte einen Pin über, und hat sich gedacht, es schadet nicht, dahin das BALE-Signal vom Mainboard zu routen. Etwas ernster: Wie Du aus den Diagrammen siehst, zeigt die fallende Flanke von BALE an, dass Du auf den SAx-Leitungen eine gültige Adresse findest. Damit kann der Adressdekoder schon ein paar Nanosekunden früher anspringen, als wenn er auf eines der Zyklus-Signale wartet. Das Board braucht BALE, da dadurch das Latch auf dem Board gesteuert wird, was A0 bis A7 während eines Zyklus hält, während der Prozessor die dafür genutzten Pins auf D0 bis D7 umfunktioniert hat.

Die Zahlen geben den zeitl.Absttand in ns an, aber es ist aus dem Text nicht erkennbar, ob es min. oder max. Zeiten sind.

Doch. Vor den Zahlen steht ein "größer-als"-Zeichen für Minimal-Zeiten oder ein "kleiner-als"-Zeichen für Maximalzeiten.

ISA hat noch eine fiese Falle zu bieten: (...)

Ja, über /AEN bin ich auch schon gestolpert. Ich denke ich werde in VHDL MEMR/MEMW/IOR/IOW in einen 4-bit Vektor zusammenfassen und dann nur reagieren wenn exakt ein Bit=GND ist. Das sollte mich von der von Dir genannten Falle hoffentlich retten.

Sollte funktionieren. Die kanonische Lösung ist allerdings, AEN in den IO-Adress-Dekoder mit aufzunehmen, und nur bei /AEN=low matches zu generieren.

Bei einem DMA-Schreib-Zyklus (memory-to-IO) werden also gleichzeitig MEMR und IOW getrieben.

Ich verstehe das Konzept so, daß mit "DMA" hier ausschließlich der DMA Baustein 8237A gemeint ist, obwohl ein ISA Device auch als DMA-fähiges Gerät auftreten kann. Nur, daß wir dieselbe Sprache sprechen. Sonst bitte korrigieren!

Sicher, daß Du da nicht ISA-Busmaster Zugriffe meinst, also wenn z.B. ein SCSI Controller selbst Daten ins RAM schaufelt/bzw. heraus?

Ja, ganz sicher. Bei Busmaster-Zyklen treibt der Busmaster (genau wie das Mainboard bei Prozessor-Zyklen) immer nur eine der Zyklus-Leitungen. Nur bei 8237-Zyklen kommt es zu dieser Doppel-Signalisierung. Ich vermute, die Idee ist, dass /IOW und /IOR zur Steuerung von Datenpuffer-Chips auf DMA- und I/O-fähigen Karten verwendet werden kann, und diese Logik unabhängig davon ist, ob DMA oder PIO stattfindet. Denke hier an sowas wie die Anbindung des NEC µPD765-Floppy-Controllers. Der hat seinen "Datenport", über den auch die Inhaltsdaten der Diskette transferriert werden. Bei Verzicht auf DMA kann der Datenport mit IN-Befehlen (im PC: auf Port 3F5) gelesen werden, und bei DMA durch den DMA-Controller. Für den Datenpfad sehen beide Varianten gleich aus.

[Jackintosh]

Und wenn man dann ein System hat, wo aller Speicher jenseits von 256KB (also die restlichen 384KB der 640KB konventionellem Speicher plus etwa 128KB in den UMBs) bei einem Taskswitch einfach werden umgemappt werden kann, sollte das in der Tat benutzbar sein.

Jetzt verstehe ich auch das LIM 4.0 Feature 'konventionellen' Speicher einzublenden. Ich bin bis dato immer davon ausgegangen, dass man ein Mainboard problemlos auf 640KB aufrüsten kann. Aber wenn man einen SW/HW Mechanismus hat, der einen bestimmten Bereich < 640K über Bankswitching ummappen kann, dann macht das alles wieder Sinn. Das braucht dann wohl bestimmte Compiler, die dieses Feature auch unterstützen?

Sobald man einen 286 hat, stellt man für Windows am besten die EMS-Karte in die Vitrine, in der coole obsolete Hardware ausgestellt wird, und lässt Windows im Standard-Modus laufen, wo es Extended Memory nutzen kann.

Ich habe ein 286 Mainboard und da ist onboard bei 1MB Schluss.
Bezogen auf <= 286 Systeme ist ein Vorteil von EMS doch, dass man schnell auf Speicher aufgrund des Bankswitchings zugreifen kann, wohingegen bei XMS kopiert werden muss? Nachteil von EMS ist dann auf <= 286, dass es wohl nur über (langsame) Steckkarten verfügbar ist.
Was ist jetzt DER Vorteil von XMS? Ich sehe immer das zeitaufwendige Umkopieren als Hemmschuh.

Ich kann Dir noch einen Tipp geben, der die Komplexität im CPLD senken könnte: (...)

Klingt interessant! Das muss ich mir aber erstmal in Ruhe aufmalen und grübeln. Ich habe schon festgestellt, daß der Synthesizer nicht so intelligent ist wie gedacht z.B.

Code: Alles auswählen

if (ADDR(24 downto 21) >= "1000") and (ADDR(24 downto 21) <= "1001") then -- Adressbereich $800000..$9FFFFF

mehr FunctionBlocks frisst, als

Code: Alles auswählen

if (ADDR(24 downto 22) = "100") then -- Adressbereich $800000..$9FFFFF

Dachte, der kann das optimieren.

Du solltest aber wissen, dass der Pin B8 auf dem ISA-Bus erst ab dem AT (mit seinen 16-Bit-Slots) die Funktion 0WS hat.

Dann gebe ich immer 0WS vom CPLD aus, wenn es Sinn macht und hänge zw. CPLD und ISA einen Jumper.

Das Board braucht BALE, da dadurch das Latch auf dem Board gesteuert wird, was A0 bis A7 während eines Zyklus hält, während der Prozessor die dafür genutzten Pins auf D0 bis D7 umfunktioniert hat.

Stimmt... Adress- und Datenbus sind ja an der CPU in den unteren acht Bit gemultiplext.

Doch. Vor den Zahlen steht ein "größer-als"-Zeichen für Minimal-Zeiten oder ein "kleiner-als"-Zeichen für Maximalzeiten.

Asche... mehr Asche!

Sollte funktionieren. Die kanonische Lösung ist allerdings, AEN in den IO-Adress-Dekoder mit aufzunehmen, und nur bei /AEN=low matches zu generieren.

PIO Zugriff bei /AEN = HIGH, oder?

Mit dem Schaltplan sollte ich heute Nacht fertig werden, kann ja einiges vom ST übernehmen. Und die Signale am ISA sind auch recht layout-freundlich!

[mkarcher]

Aber wenn man einen SW/HW Mechanismus hat, der einen bestimmten Bereich < 640K über Bankswitching ummappen kann, dann macht das alles wieder Sinn. Das braucht dann wohl bestimmte Compiler, die dieses Feature auch unterstützen?

Das Feature wird eigentlich nur vom Task-Switcher im Betriebssystem genutzt, also z.B. Windows 3.0 oder DesqView als Multitasking-Umgebung für DOS. Diese Teile wurden traditionell in Assembler geschrieben, so dass Compiler-Unterstützung hier eher unüblich ist.

Sobald man einen 286 hat, stellt man für Windows am besten die EMS-Karte in die Vitrine, in der coole obsolete Hardware ausgestellt wird, und lässt Windows im Standard-Modus laufen, wo es Extended Memory nutzen kann.

Ich habe ein 286 Mainboard und da ist onboard bei 1MB Schluss.
Bezogen auf <= 286 Systeme ist ein Vorteil von EMS doch, dass man schnell auf Speicher aufgrund des Bankswitchings zugreifen kann, wohingegen bei XMS kopiert werden muss? Nachteil von EMS ist dann auf <= 286, dass es wohl nur über (langsame) Steckkarten verfügbar ist.
Was ist jetzt DER Vorteil von XMS? Ich sehe immer das zeitaufwendige Umkopieren als Hemmschuh.

Offenbar ist der Kernpunkt der Aussage nicht deutlich genug geworden. Ich habe in dem Satz von Windows, nicht von DOS geschrieben. Und der sogenannte Standard-Modus von Windows 3.0/3.1 ist der 16-Bit protected mode des 286-Prozessors. Der Witz an Extended Memory (z.B. verwaltet durch den XMS-Treiber) ist, dass der 80286 im Protected Mode, wo er 24 Bit Adressraum direkt unterstützt, ohne jede Mapping oder Kopieroperation auf den gesamten Speicher zugreifen kann. Die 8086-Unterstützung durch den Real Mode wurde in Windows 3.1 gestrichen, und ebenso die EMS-Unterstützung. Für Real-Mode-Anwendungen ist EMS ohne Kopieroperationen definitiv günstiger als XMS.

Du solltest aber wissen, dass der Pin B8 auf dem ISA-Bus erst ab dem AT (mit seinen 16-Bit-Slots) die Funktion 0WS hat.

Dann gebe ich immer 0WS vom CPLD aus, wenn es Sinn macht und hänge zw. CPLD und ISA einen Jumper.

Das klingt vernünftig, sofern Du einen Pin im CPLD für 0WS erübrigen kannst.

Sollte funktionieren. Die kanonische Lösung ist allerdings, AEN in den IO-Adress-Dekoder mit aufzunehmen, und nur bei /AEN=low matches zu generieren.

PIO Zugriff bei /AEN = HIGH, oder?

Ich habe gerade noch mal nachgeschlagen. Ich habe im Internet mal die "Intel ISA specification, Version 2.01" gefunden und runtergeladen, und da ist auf Seite 53 ein Diagramm, in dem DMA-Zyklen gezeigt werden, und AEN (wird dort als "active high" interpretiert) während des 8273-DMA-Zyklus auf High-Pegel liegt. Also PIO wenn AEN low ist.

[Jackintosh]

Der Witz an Extended Memory (z.B. verwaltet durch den XMS-Treiber) ist, dass der 80286 im Protected Mode, wo er 24 Bit Adressraum direkt unterstützt, ohne jede Mapping oder Kopieroperation auf den gesamten Speicher zugreifen kann.

Schön und gut. Aber was macht man bei einem 286 Board wie meinem, das nur 1MB RAM onboard bietet und man mehr RAM für Windows benötigt? Da hilft einem der 286 Protected Mode doch auch nichts. Also zurück zu 8086 RealMode + EMS und Windows 3.0?

Also PIO wenn AEN low ist.

Bin immer noch verwirrt: Auf S.55 des von Dir zitierten Dokuments läuft doch ein DMA Zyklus und da ist AEN low während DACK auch low ist.
Auf S.53 ist AEN ist high und DACK wieder low.

Aber es kommt noch besser: Auf S.50 ist ein Refresh Zyklus abgebildet. /MEMR ist dabei zeitweise low. Muss ich jetzt /REFRESH auch noch auswerten oder liefert mir /BALE (=HIGH) schon Hinweis darauf, dass es kein MemoryZyklus ist?
Die c't Diagramme klammern hier elegant /BALE auch aus.

[mkarcher]

Der Witz an Extended Memory (z.B. verwaltet durch den XMS-Treiber) ist, dass der 80286 im Protected Mode, wo er 24 Bit Adressraum direkt unterstützt, ohne jede Mapping oder Kopieroperation auf den gesamten Speicher zugreifen kann.

Schön und gut. Aber was macht man bei einem 286 Board wie meinem, das nur 1MB RAM onboard bietet und man mehr RAM für Windows benötigt? Da hilft einem der 286 Protected Mode doch auch nichts. Also zurück zu 8086 RealMode + EMS und Windows 3.0?

Nein, man steckt eine 16-Bit-Extended-Memory-Karte in einen 16-Bit-ISA-Slot. Das original 5170-Mainboard von IBM (der AT) konnte sogar nur 512KB auf dem Mainboard, und aller anderer Speicher musste über ISA-Karte(n) dazugepackt werden. AT-kompatible Computer mit 6 oder 8MHz lassen den ISA-Bus auf Prozessortakt laufen, und eine 16bit-0WS-Karte kann den Prozessorbus in voller Geschwindigkeit bedienen. Ein Beispiel für so eine Karte ist diese IBM-Karte: https://www.minuszerodegrees.net/5170/c ... #512_2_meo

Also PIO wenn AEN low ist.

Bin immer noch verwirrt: Auf S.55 des von Dir zitierten Dokuments läuft doch ein DMA Zyklus und da ist AEN low während DACK auch low ist.
Auf S.53 ist AEN ist high und DACK wieder low.

Seite 55 ist ein Busmaster-DMA-Zyklus. Busmaster-DMA-Zyklen sehen auf dem Bus für die anderen Teilnehmer genauso aus wie Prozessorzyklen, und können PIO sein, und dann die I/O-Adresse des Ziels auf dem Bus haben. Nur bei 8237-Zyklen, wie auf Seite 53 ist ein IOR oder IOW-Signal auf dem Bus, und gleichzeitig eine Memory-Adresse.

[Jackintosh]

Nein, man steckt eine 16-Bit-Extended-Memory-Karte in einen 16-Bit-ISA-Slot.

Wusste nicht, daß es sowas gibt!

Wegen /REFRESH habe ich mir gestern abend mal vier ISA Karten angescheut:

• bei drei VGA Karten ist B19 (/REFRESH) angeschlossen
• bei einer Multi-I/O (IDE,FDD,RS232,LPT) hingegen nicht

Sonst werde ich mal ein ISA Board aufbauen und mit dem Oszi prüfen, welche Pegel AEN oder /BALE bei /REFRESH=GND haben. Hatte 81 Pins frei am CPLD und die sind jetzt alle belegt.

[mkarcher]

Wegen /REFRESH habe ich mir gestern abend mal vier ISA Karten angescheut:

• bei drei VGA Karten ist B19 (/REFRESH) angeschlossen
• bei einer Multi-I/O (IDE,FDD,RS232,LPT) hingegen nicht

So wie ich das verstehe, wird bei /REFRESH ein dummy-Lesezyklus ausgeführt. Für Karten, die einfach nur SRAM oder ROM enthalten, stört die Ausführung dieses Zyklus als regulärer Zyklus nicht. Für DRAM-Karten muss ggf. eine Spezielbehandlung stattfinden, da bei /REFRESH alle Bänke aktiviert werden müssen. Im Spezialfall, dass man RAM-Chips mit einem 256er-Refresh-Zyklus hat, keinen Page Mode nutzt, die Row-Nummer aus den untersten 8 Bit stammt, und die Ziel-Bank nur durch /CAS-Auswahl und nicht durch /RAS-Auswahl selektiert wird, braucht selbst eine DRAM-Karte keine Spezialunterstützung für /REFRESH.

VGA-Karten müssen /REFRESH abfangen, weil in den 16-Farb-Grafikmodi Lesezugriffe nicht nur Daten aus dem Grafikspeicher zum Prozessor befördern, sondern auch den internen Status der Karte verändern (insbesondere das 32-Bit-Datenlatch). Daher müssen VGA-Karten Zyken mit aktivem /REFRESH ignorieren.

AEN wird nicht einheitlich sein. Auf einem normalen PC/XT wird AEN high sein, denn der Refresh wird durch DMA-Kanal 0 realisiert. /REFRESH ist meines Wissens nach eigentlich DACK0 in der PC-Architektur. Auf einem AT ist das dann aber genau anders herum. Refresh wird dort getrennt vom 8237 implementiert, also bleibt AEN bei Mainboard-Refresh-Zyklen low. Das gleiche gilt für den Fall, dass eine ISA-Busmaster-Karter den Bus mehr als 15µs am Stück belegen will. Dann verpasst nämlich das Mainboard einen Refresh, und die ISA-Karte muss selbst einen Refresh-Zyklus generieren. Die Adresse kommt meines Wissens nach weiterhin vom Mainboard.

In der Praxis sollte AEN für den Refresh keine Rolle spielen, denn AEN muss man nur bei I/O-Zugriffen berücksichtigen, Refresh-Zyklen sind aber Speicher-Zugriffe.

Auf BALE würde ich mich bei einem Refersh-Signal auch nicht verlassen. BALE kommt ja aus dem Interface zwischen CPU und Bus, und ich könnte mir vorstellen, dass je nachdem, in welchem Zustand der Prozessor gerade ist (Bus idle oder Bus benötigt), BALE während eines Refresh-Zyklus mal high und mal low ist.

[Jackintosh]

Gut, dann mal Klartext: im Buch "AT Bus Design" von Ed Solari steht zum Refreshzyklus, daß die anderen /COMMAND Leitungen nicht getrieben werden dürfen und die anderen Address und Datenleitungen (ich nehme an, er mein hier speziell A[8..19]) sich im tristate befinden sollten: "All other address and data lines should be tristated by all other resources to prevent buffer fights."
Idee: das /OE das Latches (74LVC646), das u.a. als Pegelwandler zwischen SDRAM und ISA sitzt mit /REFRESH über ein NAND-Gatter mit dem OE Output des CPLDs (das momentan direkt an das Latch als /OE geht) zu verknüpfen:

Latch.gif (13.07 KiB) 7896 mal betrachtet

d.h. das CPLD gibt momentan ein low-active /OE raus (oberer Teil). Mit dem NAND dazwischen (unterer Teil) drehe ich es zu high-active, damit es in die Wahrheitstabelle passt. Oder hast Du eine bessere Idee?