Robotron EC1834 - Modifikation für XT Kompatibilität ("Tronix-Mod")

Ich habe gerade Mal die ne2000 Treiber (8/16) verglichen.

GitHub - yeokm1/ne2000plus-collection: Collection of NE2000+ software obtained from various sources

Collection of NE2000+ software obtained from various sources - GitHub - yeokm1/ne2000plus-collection: Collection of NE2000+ software obtained from various…

github.com

Der Unterschied ist wahnsinnig gering...

Im 8 Bit Treiber ist in Zeile 169 das hier auskommentiert:

;	inc	cx		; make even
;	and	cx,0fffeh

weiter in Zeile 263 auskommentiert:

init_card:
;get the board data. This is (16) bytes starting at remote
;dma address 0. Put it in a buffer called board_data.
assume	ds:code


;	or	endcfg,ENDCFG_WTS

Und in Zeile 305 ein zusätzliches "in al,dx". Vermutlich aus Timing-Gründen.

sp_read_loop:
in	al,dx		; get a byte
in	al,dx		; get a byte
stosb			; save it

Der Rest ist String oder Leerzeichen.

Aber der Kommentar vor Zeile 263 irritiert mich. Da steht wieder was von DMA.

Könnte aber vielleicht auch ein DMA Transfer in der Netzwerkkarte sein.

Initialisieren tut der Treiber jedenfalls.

Vielleicht gibt es hier "nur" ein Timing-Problem mit dem IO16 Signal...

Ich müsste das mit einem anderen Rechner vergleichen. Eine Messung habe ich ja.

Bei den Grafikkarten im 16 Bit Modus ist der größte Teil ja der Speicherzugriff, anstelle von IO.

Die Prototyp Platine ist da.

Damit sieht es doch gleich viel besser aus. Funktion bleibt gleich.

Die Lötbrücken sind für Pull-Up der ungenutzten Eingänge oder zur Nutzung der Gatter bei Bedarf.

Gruß Mario

Zum NE2000...

Doch, der Treiber macht 16 Bit transfers...

rep outsw

oder

rep insw

Abhängig von der CPU. Bei einem 8086 sollte er eigentlich bei 8 Bit bleiben.

Alles größer/gleich 80186 wird dann zu obigem.

Ich habe NEC V30 da, aber noch nicht getestet. Zur Erkennung der CPU wird "shift count mod 32" im NE2K Treiber genutzt, was dann wohl den NEC als 80186 identifizieren soll.

Der DMA Transfer ist intern im RTL8019.

Wenn Daten gesendet werden sollen, wird beim schreiben in das Data Register einfach jedens Byte in den SRAM geschrieben.

Anschließend wird dann der DMA gestartet und die Daten von dort auf Reise geschickt.

Was ich beim IOCS16 wohl nicht bedacht habe, sind Lesezugriffe auf ungerade Adressen.

Ich habe heute was in der c't 11/91, S.336 gefunden:

Zugriff auf 16 Bit Memory oder I/O


SA0	/SBHE 	/xxCS16	SD0...SD7 	SD8...SD15
Word Adr0	0 	0 	0 	<Adr0> 	<Adr1>
Word Adr1	1	0	0	-	<Adr1>
0	1	0	<Adr2> 	-
Byte Adr0	0	1	x	<Adr0>	-
Byte Adr1	1	0	0	-	<Adr1>
Byte Adr1	1	0	1	<Adr1>	-
ungültig 	1 	1 	x 	- 	-


Zugriff auf 8 Bit Memory oder I/O


SA0 	/SBHE 	SD0...SD7
Word Adr0 	0	x 	<Adr0>
1	x 	<Adr1>
Word Adr1 	1 	x 	<Adr1>
0 	x 	<Adr2>
Byte Adr0 	0 	x 	<Adr0>
Byte Adr1 	1 	x 	<Adr1>


Beim 16-Bit-Memory nimmt die Bus-Konvertierlogik auf dem Motherboard der Peripherie viel Arbeit ab. Sie bewirkt, daß ein `misaligned´ Wordzugriff (das sind solche auf eine ungerade Adresse) in zwei aufeinanderfolgende 8-Bit-Zugriffe umgemünzt wird und daß die Peripherie bei Byte-Zugriffen auf ungeraden Adressen diese auf der oberen Datenhälfte anliefern darf (falls /MEMCS16 oder /IOCS16=0). Dadurch wird das Design der Peripheriekarte erheblich vereinfacht.

Diese Logik fehlt definitiv für den IO Zugriff bei D22. D.h. ich kann mir da im Moment weitere Experimente sparen. Hardware die hier irgendwelche Zugriffe erfordert, dürfte nicht funktionieren. Alles was gerade Ports nutzt könnte gehen.

Ich konnte es nicht lassen und habe mal meinen CF Adapter an den 16 Bit Mitsumi 2183M Adapter (kontrolliert vom XT-IDE BIOS als 16 Bit IDE) angeschlossen.

Interessanterweise funktioniert das. Booten will XT-IDE zwar nicht davon (Bootsector not found), aber wenn ich mit der NW DOS SD Karte von XT-IDE boote, kann ich auf die CF Karten zugreifen.

Laut checkit erhöht sich die Geschwindigkeit auf 229Kb/s und ist damit schneller, als der SD Adapter (auf der XT-IDE), der vorher der schnellere von beiden war.

Nicht, dass die SD Karten nur 8 Bit machen.

Hi Norbert,

Zitat von Norbert-97801

Zitat von mgoegel

Bei einem 8086 sollte er eigentlich bei 8 Bit bleiben.

Der 8086 hat einen 16-Bit-Datenbus. Der 8088 hat "nur" einen 8-Bit-Datenbus. Somit müssten theoretisch auch 16-Bit-Transfers mit einem 8086 funktionieren...

du hast hier unvollständig zitiert - es ging da NUR um den NE2K Treiber.

Klar kann der 8086 16 Bit, darum geht es hier ja, dass ich 16 Bit auf dem EC1834 zum laufen bekomme.

Ich habe sogar eine 16 Bit Mitsumi IDE Karte am Wochenende dazu gebracht, zu arbeiten. Allerdings nur halb, weil die ungeraden Portzugriffe meines

erachtens noch nicht arbeiten.

Die Tabelle aus dem c't Artikel hat mir da ordentlich Erleuchtung gebracht. Ich verstehe so langsam den Teil der Schaltung.

Allerdings noch nicht ganz. Ich muss mir da zu jedem Gatter Kommentare machen, aber ich ahne (D32.2) schon, wo ich das IOCS16 Signal noch verknüpfen muss.

Kein Problem

Ein wenig nachdenken sagt mir, dass ich D3M[Teil B] (DL008.[4,5,6]) hinzufügen muss.

D32.2 = /IOCS16 & /MEMCS16

Das müsste es dann sein... Weiß nur nicht, ob ich das jetzt vom KC85 Treffen nächste Woche noch eingebaut bekomme...

Nach den anderen BIOS Varianten hatte ich noch gar nicht geschaut.

Ich hatte bisher immer nur die XT Version genommen.

Nach einem späten Feierabend musste ich meinen Frust über "Neuland Technologie" (Fax Server an IP Cloud PBX) los werden und habe das Board nochmal umgebaut.

IDEDIAG zeigt jetzt die Daten der CF Karten an einem 16 Bit Mitsumi IDE Controller an. Zugreifen konnte ich zwar vorher auch, aber nicht korrekt.

Ich kann jetzt Programme von dort starten, was heißt, dass der Zugriff funktionieren müsste.

Bilder lade ich später noch hoch.

Hier der aktuelle Stand:

Der disktest war jetzt nicht besonders Schnell. Checkit zeigt etwas mehr an...

Eine 16 Bit Multi IO Karte funktioniert heute auch (Data4 war korrodiert, deswegen ging sie gestern nicht).

Manawyrm seine NE2000 bekomme ich leider nicht mit 16 Bit zum laufen. Der 8 Bit Treiber funktioniert.

Ich weiß nicht, ob der intern hier 16 Bit machen würde. Das könnte CPU Abhängig sein....

Gruß Mario

Habe gerade nochmal XTIDE umgeflasht.

Der MultiPort Controller wird nun auch bei der primären Adresse gefunden.

Die Geschwindigkeit konnte ich in checkit mit einer Ultra II CF Karte 2GB auf 260Kb/s erhöhen.

Laut dieser Berechnung...

...dürfte ich also nah am Maximum sein, was realistisch geht.

Eine 2GB DOM war um die 230Kb/s wieder langsamer.

Nochmal zum Vergleich auf meiner aktuellen Boot-SD via IDE-SD Adapter:

XTIDE Compat Mode: 117kb/s

XTIDE Hi-Speed Mode: 207kb/s

16Bit Mitsumi IDE: 237KB/s

Mein aktuelles Fazit ist im Moment folgendes:

Der EC1834 läuft mit 16 Bit Hardware locker doppelt so schnell, wie im Standard.

Die Tronix Modifikation alleine ist nicht ganz so schnell, erhöht aber die Geschwindigkeit enorm.

Außerdem verbessert sie auch die Softwarekompatibilität, wenn man mal etwas zocken will, was VGA angeht.

Der Aufwand für die 16 Bit Modifikation ist nicht dramatisch. Es sind 2 ICs zu sockeln und 2 Signale zu verknüfen.

Insgesamt muss für die Tronix-Modifikation folgende ICs gesockelt werden:

D11, D14 und D59

Für die Erweiterung auf 16 Bit sind es:

D7 und D32

Für den Tronix-Mod sind Verbindungen nötig:

auf Unterseite: 5

auf Oberseite: 4

Die 16 Bit Modifikation benötigt zusätzlich:

auf Unterseite: 2 oder 3 (wenn IOCS16 über die DIN Slots geführt werden soll).

auf Oberseite: 2

Ich glaube, es wäre an der zeit, eine eigene Seite dafür zu bauen...

Ja. Im RT Forum hörte ich bei einigen so kritische Kommentare von wegen verbasteln raus...

Ich habe dieses Board jetzt 1 Jahr lang repariert. Jede Änderung daran löst im Moment vertaute Gefühle aus...

Aber da Hobi mich letztes Jahr schon auf diese Erweiterung hin ansprach dachte ich mir - warum nicht.

Das Tronix Mod ermöglicht mir jetzt noch den Bau der SVGA Karte und sichert damit ein wenig die Zukunft des Rechners - was die Monitore angeht. Bis jetzt hatte ich es noch nicht geschafft, das Bild vom MON/COL Adapter irgendwo anders auszugeben.

Mal schauen, was die Jungs nächstes Wochenende in SA beim KC85 Treffen sagen werden.

Edit:

Bei der NE2000 scheint 16 Bit wohl nichts zu bringen, so, wie der Quellcode ausschaut. Außer ich modifiziere den vorhandenen Treiber und kompiliere ihn neu.

...mal schauen, ob ich ihn überhaupt Original kompiliert bekomme.

Zitat von Norbert-97801

Ich finde, das hat schon was, wenn man einen XT hat, der mit einem 8086 läuft, aber einen AT-Signal-Kompatiblen Bus hat. Das hat Seltenheitswert. Verbastelt... nun ja... würde ich so nicht sehen, da alle Änderungen bei dir Dokumentiert sind und sie sich - bei bedarf - wieder rückgängig machen lassen. Jetzt fehlt nur noch der NEC V20... Dann hätte dein Rechner einen Prozessor, der 80186-Befehlskompatibel wäre... würde ich aber nur dann machen, wenn der russische 8086 Klon Prozessor gesockelt wäre. Auslöten könnte bei dem Alter sein Tot sein.

Der Witz ist... ich habe ein paar V20 da liegen. Die sind aber nur 8088 kompatibel. Ich hätte V30 kaufen müssen.

Da war ein K1810WM86 auf dem Sockel, der tot war. Da läuft zur Zeit ein NEC 8086 drauf.

Und nein, ich habe auf dem Board alleine 9 ICs wegen defekt tauschen müssen. Während der Fehlersuche sind 8 weitere auf Sockel gelandet.

Also das wäre nicht das Problem...

Du meinst mit dem NEC D8086 jetzt? Oder dem V30?

Zur Info für die anderen mitlesenden...

Andreas vermutete einen V30, aber mein NEC D8086 scheint ein echter 8086 zu sein.

Zumindest fuktionierte das AT BIOS nicht. Der Rechner blieb dann beim Starten des BIOS hängen.

Zitat von sachse

Ich sehe hier auf machen Bildern Busadapeter und Umbauten am Mainboard.

Ich wuerde an meinem Mainboard ungern rumbasteln, allerdings sind meine beiden 8Bit-ISA Slots schon belegt.

Wie waere es wenn man eine Platine erfindet, welche das physische Layout des originalen Mainboards haette, das man es in eine zweites Gehaeuse eines EC 1834 reintun koennte.
Als Verbindung ein Kabel, was von einem der 16Bit Steckplaetze hinten durch ein Slotblech rausgeht (oder Flachband, dann passt es durch den seitlichen Gehaeuseschlitz).
Auf diesem koennte man dann nochmal 8Stk 16Bit ISA zur Verfuegung stellen.

Naive Idee von mir:
Vielleicht waere es auch moeglich die Anpassungsschaltung, von der hier die ganze Zeit die Rede ist, auf dieses Board zu bringen, so das gar keine Aenderung auf dem Originalmainboard notwendig wird.

Alles anzeigen

eine Bus Platine ist vermutlich passiv nicht bis unmöglich.

Ein neues Mainboard wäre theoretisch möglich, aber der Aufwand, das zu Routen ist enorm.

Die Modifikation ist so simpel, dass es kein Thema wäre.

Zur 8019: der Witz ist - mit der Modifikationen möchte ich erreichen, dass sie in 16 Bit funktioniert

Gruß Mario