Beiträge von DoPe

danke fritz, es ist also der 8284 ... beim 8088

und ein paar Seiten davor 2-16 in der großen übersicht der 8224 beim Z80

@WD

Wolfgang, verwendet der DMV tatsächlich den 8224 baustein? Der ist nach allem was ich dazu gefundenhabe für eine 8080 cpu gebaut worden.

Ist der im DMV weigen der Z80 cpu?

Ist im DMV (für den 8088) nicht der 8284 Taktgeber drinnen?

Und an alle technisch versierten, oder aber auch nur INteressierten das intel pdf zum DRAM controller 8203 mit Beispielen (rechnen ist angesagt) zur Ermittlung der Konfiguration eines Systems mit 0 wait - states.

@WD

Wolfgang, kannst du das mit dem Aufbau des DMV abgleichen? D.h. kannst du mit den angegebenen Formeln ausrechnen, mit wie hoch die cpu des DMV getaktet werden kann, ohne daß wait states auftreten? oder andersrum: wieviele waitstates ergeben sich bei 6,77 bzw 8 MHz ?

1ST1

ich gehe davon aus, daß die hochtaktung nur die cpu betreffen. hier wird wohl der hund begraben liegen. das ram subsystem kann nicht schnell genug nachliefern

und legt die cpu auf WAIT - die berüchtigten wait-states treten auf.

Bei den Testgeräten mit Taktumschaltung (4,77 / 9,54) sieht sehr schön, daß die Techniker sich was einfallen lassen haben. Denn die Laufzeiten zeigen eine

1:1 Umsetzung der höheren Frequenz: doppelte MHz, halbe Laufzeit.

Es ist dabei aber nicht damit getan, den Dram Controller höher zu takten. Ich habe mir die letzten 2 TAge ein intel manual zum 8203 durchgelesen, in dem Beispiele dargestellt sind, wie man das speichersystem aufbauen muß, damit keine wait states entstehen. Ich werde einen Link dazu posten bzw das pdf hier hochladen. SEHR interessant (aber auch deutlich über meinem Wissen und Verständnis).

Martin Hepperle

ja, das bloße aufaddieren der cpu cycles für die einzelnen op-codes ist nie die ganz rechnung. wie du in meinem 1. post in diesem thread im source-code nachlesen kannst, habe ich die rechnung, die jzander ursprünglich anstellte, auch dahingehend korrigiert (+8c fürs nachladen der 2. op-code bytes der beiden sprungbefehle).

ebenso muß beim aufaddieren mit dem ziel einer praxisnahen laufzeitbestimmung immer auch mitgedacht werden, daß befehle, die nicht bereits in der pipeline in der cpu bereits vorliegen, kurze op-code bytes mit laufzeiten von zb 2 cycles ( inc/dec etc) dann doch 2c + 4c (nachladen) benötigen. dase spezialität liegt beim gewählten testcode nicht an, weil wie du sehen kannst, die laufzeiten von int bzw iret weit jenseits dieser grenze liegen. beide sind aber "jmps" und die leeren die pipeline erstmal. da aber in den angegebenen laufzeiten das laden des 1. op-code bytes des nächsten befehls bereits inkludiert ist, muß noch die zeit des nachladens des 2. opcode bytes dazugezählt werden.

Daus Aufaddieren der cpu-cycles (wenn korrekt gemacht) ist selbstverständlich IMMER nur die Untergrenze der Laufzeit einer Routine.

Es kommen dazu:

* die Laufzeiten ausgelöster Interrupts während der Laufzeit (timer interrupt, keyboard eingaben)

* der refresh des rams (je nach verwendeten bauteilen und aufbau des ram-systems müssen spätestens alle 2ms oder 4ms alle speicherzeillen einmal "aufgefrischt" werden. Am IBM PC verlangsamt der refresh die Laufzeit letztlich um bis zu 8+ PRozent).

* und die wait-states (von welchem device auch immer ram/vga/....)

Ich habe das t8088ncp nochmals überarbeitet (optisch, textlich) und ein paar Zusatzinfos zur Anzeige gebracht. Am interessantesten ist wohl der RAM-throughput in kb/s, der sich beim movsw - test ergibt. Die Meßroutinen und Testroutinen haben sich aber nicht geändert, die alten Ergebnisse sind weiterhin gültig.

Hier auch wieder die Tabelle aktualisiert mit den zuletzt eingetroffenen Resultaten.

@WDreyer

Ergebnis beim 486er 133, wdspeed4: ca 59 sek

ich denke aber daß du den test abändert solltest. zur Zeit mißt dieser test vor allem die fähigkeiten des bildschirmtreibers.

ausgaben auf den bildschirm über syscalls machen den test über pc grenzen hinweg nicht vergleichbar, weil ja unterschiedliche grafikkarten und unter-

schiedliche implentationen der bildschirmtreiber (untterschiedliches Dos / ansi treiber / int21h / int10h etc) uatomatisch zu unterschiedlichen laufzeiten

führen werden.

und es ist auch ganz sicher so daß ausgaben auf den bildschirm den allergroßten teil der gemessenen zeit einnehmen.

verändere das programm dahingehend, daß du am start schreibst "press return zum starten" , danach deine routine laufen läßt (ohne bildschirmausgaben) und am ende einfach einen BEEP (ascii zeichen #7 glaub ich ausgibst).

funkenzupfer

Zitat

Ich habe in dem anderen DMV Thread schon gesagt, das diese Notizen m.E. das Problem mehr verschleiern als aufklaeren.

Eine Formulierung wie "Ursache scheint ... zu sein" zeigt klar eine Vermutung statt einer qualifizierten Messung. Und ob vielleicht noch ein anderer Einfluss oder Hardwaredefekt vorliegt, wird gar nicht eroertert.

Fuer mich ist das heutzutage Fake-News.

DoPe , ich weiss nicht warum du diese Notizen immer wieder zitierst.

Alles anzeigen

Daß es hier und heute überhaupt Kenntnis von einem möglichen Problem beim DMV hinsichtlich seiner Performance gibt, verdankt sich dem

know-how und Wissensdurst von JZander, der sich seit etwa 1985 mit DMVs beschäftigte (neben anderen Geräten) und der seinen letzten DMV ca MItte der 2010er Jahre verkaufte. Und dem Umstand, daß ich ihn 1988 kennen lernte, er meinen DMV bis MItte der 1990er betreute, und ich erst kürzlich wieder auf Aufzeichnungen von ihm aus dieser Zeit aufmerksam wurde, darunter jene über seine Erfahrungen während eines Umbaus auf 6,67 MHz die ich hier im Forum nun veröffentlichte und Interessierte DMV Besitzer bat, ob sie bereit sind einen Replikationstest auf ihrem DMV durchzuführen. Zur Überprüfung ob diese Erfahrungsbericht von Zander nachvollzogen werden kann. Liegt ein Einzelfallproblem vor oder hat der DMV generell ein Problem?

Im Gegensatz zu dir funkenzupfer saß Zander höchstpersönlich vor einem geöffneten DMV, hat die 16er Platine von 5 auf 6,67 MHz umgebaut und vermerkte dabei in seinen Notizzen (den "fake news") unter anderem auch, daß es so einfach nicht ist, weil es zu Überschwingern kommt, die durch entsprechendes Kleinmaterail gedämpft werden müssen. Was für ein Scharlatan, nicht wahr funkenzupfer?

Seine Erwartung vom Performanceschub wurde aber nicht erfüllt und so dachte er sich wohl - wenn es nach dir geht, funkenzupfer - "ich erzähl den Leuten einfach eine Geschichte und denke mir dabei ein paar Zahlen aus. DoPe der nützliche Idiot wird mir dabei helfen".

Das Gegenteil war der Fall. Der Verschleierer, Geschichtenerzähler und fake-news-Schwurbler setzte sich - im Gegensatz zu dir funkenzupfer - vor den Rechner, warf den debugger an und klopfte ein kurzes assembler Programm in die Tasten. Nahm in eine Hand eine Stopuhr und nahm Maß. Mit Sicherheit nicht nur einmal.

Und kontrollierte alles nochmal und nahm wieder Maß. Wie das jeder Otto tut wenn man bencht. Vor allem, wenn man sich vorher schlau gemacht hat und die cpu-cycles aus dem Herstellerhandbuch (total fake) für die test-op-codes aufaddierte. Und irgendwann war Schluß damit und er ließ die Nachwelt wissen: 12,8 sec handgemessen versus 8,4 sec lt. Datenblättern. Der Unterschied ist zu groß um es auf die Messung per Hand schieben zu können.

Und so dachte er nach woran das wohl liegen könnte und zog wieder einschlägige Unterlagen dazu zu Rate. Unterlagen zum DMV. Oder glaubst du er hat das erfunden: "

Ursache scheint der memory controller (8203) zu sein, der neben

dem addressmultiplexing wohl auch für reichlich viel refresh

sorgt. Dieser Baustein erzeugt ein Wartesignal, das als "readyp"

(Pin b10 an J107) auf dem Systembus liegt. Auf der 8088 Karte

wird dieses Signal über den Taktgenerator auf den ready input des

8088 geleitet und erzeugt dort zusätzliche Wartezeiten. Dieses

Signal ist etwa die Hälfte der Zeit aktiv, was ins beschriebene

Bild paßt"

Hört sich nach jemanden an, der keine Ahnung hat, oder? Nein, JZander hat seine Aufgaben gemacht, lieber funkenzupfer. Er hat abschließend eine Hypothese ("Vermutung") aufgestellt, was die Ursache sein könnte. Er hat nicht gesagt, daß es so ist. Das wäre unredlich, weil er die Hypothese nicht überprüft hat. Er läßt es offen, warum die Messung so deutlich über dem Sollwert lag. So gehört sich das. Und hat sich anderen Dingen zugewendet und lebte trotzdem glücklch mit seinem DMV weiter.

Und was machst du, funkenzupfer. Du stellst es so dar als hätte Zander nicht "qualifiziert gemessen" (wie bitte?) und stattdessen nur billigerweise "vermutet".

Das lieber funkenzupfer ist intellektuell eine Pleite, insbesondere wenn du sogar selbst zugibst, den thread gar nicht von Anfang an gelesen zu haben. Und dir dennoch eine abwertende Beurteilung der Arbeit eines Nichtanwesenden erlaubst.

Dieser thread dient dazu, Licht ins Dunkel zu bringen. Hat der DMV eine schlechte Performance oder nicht? Das muß erstmal festgestellt werden. Wir bemühen uns. Und viele Erkenntnisse sind durch die Einsendungen der Testergebnisse schon entstanden, als Nebenprodukt sozusagen. Leider ist aufgrund der mangelhaften Ausstattung der DMVs an Interruptcontrollern noch kein Ergebnis von einem DMV eingetroffen. Es wird schon, bin zuversichtlich.

Und wenn der DMV am Ende doch perfekt performed dann sind wir eh alle froh. Und Zander hat dann eben einen Einzelfallrechner gehabt. Aber trotzdem nicht fake news verbreitet.

Dank dir, lieber funkenzupfer, und ich meine das jetzt genauso ernst wie das obige, wird sich die DMV Situation verbessern. Danke für deine Bemühungen in Sachen K235plus etc. Chapeau!

Da ich im Moment sowieso keinen Zugang zu meinem DMV habe, und wohl auch in den nächsten Wochen bis Monaten nicht,

lasse ich gerne Schroeder den Vortritt.

PAW

ad 2 zuerst)

Der DMV ist von Haus aus eine interrupt-lose Maschine (ursprünglich eine reine CP/M Maschine). Schon nach wenigen Monaten ab Verkauf (1982) hat NCR das mainboard überarbeitet und für eine 16-bit (8088) Zusatzplatine aufbereitet, auf welcher dann ein 8259 Interrupt-controller drauf war oder auch nicht.

Erst mit 8259 Baustein funktioniert auch der Timer Interrupt (unter DOS), er erlaubt aber auch eigens dafür adaptierten (kleine HW-Änderung notwendig) Zusatzplatinen (in der Regel angeschlossen über den extern zugänglichen Bus) ebenfalls Interrupts auszulösen. Notwendig war darüberhinaus aber auch immer, daß ein entsprechender "Treiber" installiert wurde, der eine entsprechende Interrupt Service Routine im Interrupt Table verlinkt und bereitstellt und dann dem 8259 dies mitteilt. Die Timer Interrupt Service Routine wurde automatisch beim Booten von DOS installiert und aktiviert und kostet sicher nicht mehr Zeit als auf einem XT, da die Verfahrensweise zum Aktualisieren der Systemzeit gleich ist.

D.h. mit anderen Worten: schlechte Performance wegen zu häufiger Interrupts gibts am DMV eigentlich nicht.

Das Keyboard löst keinen Interrupt aus, es wird bei Bedarf gepollt.

ad 1 wait-states)

Ich weiß es nicht. Vielleicht kann Wolfgang Dreyer dazu etwas sagen, er war damals bei der Entwicklung dabei.

JZander meinte jedenfalls, ich zitiere aus seinen Notizzen:

Zitat

System Info von Norton liefert am original DMV einen computing

index von 0,9, mit deh V20 erhöht sich dieser Wert auf 1,6 und

bei eineh 20 MHz Quarz auf 1,9. Die folgenden Zeitmessungen

ergeben effektive Laufzeiten, die etwa doppelt so lang sind wie

die aus der Taktfrequenz und Anzahl der Zyklen errechneten Werte.

Ursache scheint der memory controller (8203) zu sein, der neben

dem addressmultiplexing wohl auch für reichlich viel refresh

sorgt. Dieser Baustein erzeugt ein Wartesignal, das als "readyp"

(Pin b10 an J107) auf dem Systembus liegt. Auf der 8088 Karte

wird dieses Signal über den Taktgenerator auf den ready input des

8088 geleitet und erzeugt dort zusätzliche Wartezeiten. Dieses

Signal ist etwa die Hälfte der Zeit aktiv, was ins beschriebene

Bild paßt.

Alles anzeigen

tokabln

wenn man die ergebnisse mit denen des NuXT (S-RAM) vergelcht, dann würde ich sagen, dein Rechner hat auch S-RAM ....

oder es ist das c't bios welches den gleichstand trotz DRAMS herstellt ...

Wieso soll eine langsame CPU wie der Z80 (4 MHz) nicht mit RAM umgehen können, das selbst mit 8 MHz CPUs betrieben werden kann?

Nach unten ist immer Luft ...

1ST1

mein DMV läuft mit 8 MHz ... (kann aber nicht mittesten weil zZt unzugänglich verstaut)

WD (Wolfgang Dreyer) hier im forum (Techniker bei der Entwicklung des DMV) hat dazu zumindest gesagt, daß der DRAM controller im DMV genauso eingebaut und benutzt wird wie beim XT.

DIe Lösung des RAM Performance-Problems des DMV wird sich vielleicht auf ganz anderem Wege letztlich ergeben, weil zZt gerade RAM-Erweiterungsplatinen für den DMV entwickelt werden, die mit SRAM bestückt sind. Und wenn es so ist wie der Hauptentwickler funkenzupfer kürzlich feststellte, daß der DRAM controller auf dem mainboard stillgelegt werden kann, dann iwurde aus der Not eine Tugend und der DMV wird schneller als erlaubt

tokabln

ja, diese MHz info werde ich bei der Anzeige mit den Ergebnissen einarbeiten. Dann weiß man wenigstens (falls screenshot gezeigt wird) ob einer getrickst hat, denn diese Angabe fließt in die Berechnung der Effizienz ein.

Berechnung:

"Effizienz" = RunTime(µsec) * ( 1 / MHz) = Anzahl der CPUcycles used

1ST1

ich kann die Frage nach der Taktung des RAMs nicht wirklich beantworten. Ich glaube das funktioniert bei diesen alten Rechnern anders.

Das Anzeichen (eigentlich der Beleg) dafür sind die ausgewiesen Laufzeiten bei den Rechnern, wo jemand einmal mit 4,77 und ein weiteres Mal mit 9,54

getestet hat. Man sieht hier eindeutig, daß die Laufzeit 1:1 sich halbiert, wenn der Takt verdoppelt wird. Das heißt, das RAM wird mit der Geschwindigkeit der CPU angesprochen.

siehe:

1ST1

ja, für alle cpus gleich.

tokabln

welche mhz zahl wurde eingegeben? 4,7 nehme ich an, oder? man sollte immer möglichst genau die mhz eingeben,

das dritte bild nehme ich an ist vom tinput - test? dieser test ist obsolet, er diente einer fehlersuche und das problem ist behoben.

beim tinput test scheint jedenfalls 4,7 eingegeben worden zu sein, weil der Kehrwert davon die angezeigten 0,2128 (gerundet) ergibt.

falls die ergebnisse von bild 1 und 2 mit 4,7 mhz eingabe gemacht wurden, der tats. takt aber 4,77 ist -> bitte test nochmal durchführen

Kennt jemand ein tool mit dem man zuverlässig bei alten rechnern feststellen kann, welche Taktung tatsächlich anliegt?

Ja, der Z80 dient zum Booten / Initialisieren, wenn der bootsector gelesen wurde, wird entschieden ob es mit dem Z80 (cp/m) oder 8088 (dos) weitergeht.

die motorola 68008 kann glaube ich mit dem p-system genutzt werden, habe das aber nie ausprobiert.

ich freu mich riesig wenn das alles dann funktioniert.

Hier ein Auszug aus den eingereichten Daten zur Auffindung möglicher Performance Probleme des DMV.

Man sieht hier Werte eines PCs mit V20 + S-RAM sowie eines 8088 + D-RAM bei gleicher Frequenz. Als hätte man die Prozessorklasse gewechselt.

Der Analyse Teil 2:

Zuerst noch Wiederholung und eine Ergänzung zum Teil 1.

Beide CPUs absolvieren den JMP-Test langsamer als "am Papier steht", V20 um 12%, 8088 um 3%.

In der Theorie ergab sich rechnerisch ein Laufzeitunterschied zwischen V20 und 8088 von 27 % zugunsten des V20.

Die Praxis zeigte, daß dieser Unterschied real nur 16,8 % beträgt.

JZander ermittelte für den JMP-Test eine Laufzeit von 12,8 Sek, bei 6,67 MHz (V20).

Bei 6,67 MHz sollte theoretisch die Laufzeit 8,24 Sek betragen. Addiert man versuchsweise zu diesem theoretischen

Wert 12% (aus dem Praxisbeispiel oben) hinzu, ergibt das eine prognostizierte Laufzeit in der Praxis von 9,2 Sek.

Einen Eintrag für einen V20 mit 6,67 MHz haben wir in Tabelle noch nicht, auch keine Laufzeit in dieser Größe.

Aber da läßt sich dank einer beobachtbaren Linearität ein Wert errechnen.

Einmal gibt es da die 2 Ergebnisse des Commodore PC20 (8088), mit 4,77 und 9,54 MHz

und weiters den NuXT 2.0 (mit V20), ebenfalls mit 4,77 und 9,54 MHz

Man sieht an deren Ergebnissen, daß die Laufzeiten sich linear zur Taktung verhalten, doppelte MHz = halbe Laufzeit, also

offensichtlich das ganze System 1: 1 mitmacht. Das heiißt dann aber auch, daß die "Efficiency" (CPU-cycles)

gleich/stabil/konstant (bis auf ein geringes Rauschen) bleibt! Diese Logik mache ich mir im Folgenden zu eigen.

Damit läßt sich am Beispiel des Commodore PC20 (8088 !!!) ein Wert für 6,67 MHz Taktung rechnerisch aus den Praxisdaten ermitteln.

Dazu nimmt man den Wert aus "Efficiency" Spalte, die die Anzahl der verbratenen CPU-cycles angibt und dividiert sie durch

den Wert der MHz, für die man die Laufzeit errechnen möchte. Ich verwende den Commodore PC20 (8088), weil wir den Unterschied in

Laufzeit des 8088 zum V20 bereits berechnet haben und somit das Ergebnis noch korrigieren können. Der NuXT verwendet zwar den V20, aber

verwendet SRAM (ohne refresh), weshalb seine Laufzeiten von vornherein kürzer und daher nicht korrekt korrigiert werden könnte.

eff 72.289.782,1 / MHz 6,77 = 10,8 Sekunden (8088)

Korrektur: Der V20 ist lt. Praxistest 16,8 % schneller als der 8088, somit beträgt die Laufzeit für V20 (6,77 MHz) = 9,3 Sek

Wenn meine Annahmen und mein Rechengang richtig sind und JZander auch keine Fehler gemacht hat, dann hat

der DMV tatsächlich ein Problem. Gemessene Laufzeit 12,8 Sek, "errechneter" Soll-Praxiswert 9,3 Sek.

Der Unterschied ist "kein Lercherl" wie man in Wien sagt.

funkenzupfer

ich habe ein 512kb Modul .... aber wenn ich der einzige wäre zZt mit dem Wunsch nach der k235plus+RAM dann ist das nicht so wichtig

und wenn diese dram-refresh sache sich tatsächlich "reparieren" läßt, dann könnte ich bei Abschaltung des refreshs die alten 512 DRAM eh nicht mehr nutzen.

Wie ist das eigentlich mit den 64KB Grundspeicher, welcher auf dem mainboard von Haus aus eingebaut ist. Werden die bei Verwendung der K0815 abgeschaltet?

wenn diese bausteine fürs Booten weiterhin notwendig ist, dann wird es wohl nix mit dem Abschalten des refreshs, oder irre ich da?

trazom

Es ist tatsächlich machbar, die DMV-Tastatur nachzubauen? Da wäre ich jedenfalls dabei!

funkenzupfer

ich nehme alle 3: k235plus, k235plus mit RAM, sowie K0815 RAM

PAW

ad CPU Identifizierung: suche mal nach dem tool "speccy64" bzw "speccy32" im Netz ....

ad "Effizienz"-Spalte

der Grund warum im Vergleich zu anderen CPUs manche erstaunlich schlecht / gut abschneiden, liegt an der "Prozessorarchitekur" einerseits und dem Stück Programm das es abzuarbeiten hat. Der Testcode JMPorgy ist ein voll synthetischer und an sich nutzloser Code. Mit so einem Code der nichts anderes tut als 1 Million Mal (2x500000) einen "FAR JMP" auszuführen (zum int80 und retour) ist kein Blumentopf zu gewinnen. Darauf ist keine CPU seit dem 486er mehr vorbereitet, sie sind intern so ausgelegt, daß typische Programme schnellstmöglich ausgeführt werden, nicht aber so ein "Test". Er läuft dem internen Aufbau solch moderner CPUs zuwider. Daher schneiden alte CPUs im Vergleich dazu relativ viel besser ab. Den Vogel schießt hier der 486er ab, mit der schlechten "Effizienz" überhaupt. Die Werte in dieser Spalte sind für sich bedeutungslos, man kann sie immer nur im Vergleich mit anderen verwenden (also anderer Architektur) . Niedrigere Werte sind besser und bedeuten eine "produktivere" Umsetzung der MHz in Leistung (ops/sec). Die Zahl die in dieser Spalte steht kann kann man als CPU Zyklen" verstehen, die "verbraten" werden mußten/wurden, um das Testprogramm zu absolvieren. Je weniger, desto effizienter wurden die CPU clocks verwendet.

1ST1

vielen dank fürs posten in vcfed ... Die Erklägurng zu "ops/sec" ist aber nicht ganz korrekt bzw. könnte mißverstanden werden.

Daher für die technisch Interessierten: Es ist nicht die Anzahl der "loops" (klingt nach Hochsprachen-Programmierung) die pro Sekunde ausgeführt werden, sondern die Anzahl der Ausführungen des Testkerns.

Der Kern im Falle der JMPorgy ist "int 080H" x 500000.

Alle Werte sind durch Herausmessen "befreit" von jeglichem overhead der durch TP entsteht, also auch die Laufzeit der FOR-TO-LOOP (die es tatsächlich im sourcecode gibt und nur 1 Aufruf der testroutine erzeugt, aber vorhanden ist um flexibel zu bleiben). Ebenso herausgemessen wird der (1malige) Aufruf der Testprozedur und dessen Rücksprung (call / ret), sowie alle in der Testroutine enthaltenen Anweisungen die für das setup der Kernroutine notwendig sind aber nicht in die Laufzeitmessung hineingehören. D.h. der Wert "ops/sec" gibt an, wie oft die "Aktion" (500000 x int80h) in einer Sekunde ausgeführt werden kann.

Dieses "Runterbrechen" auf den Testkern habe ich mir deswegen angetan, weil ja ursprünglich von JZander dargelegt wurde, daß der DMV entgegen dem Erbsenzählen (Summierung der lt. Manual ausgewiesen cpu-cycle times aller für die Abarbeitung von 500000 x int80h notwendigen op-codes) deutlich länger braucht. Ich wollte und will also möglichst genau an die "wahre" Laufzeit heran, um die Beobachtung Zanders bestätigen oder verwerfen zu können.

Und somit zurück zur ursprünglichen Frage, ob J.Zander tatsächlich Recht hat, daß der DMV ein Performanceproblem hat, welches er schlechter RAM performance zuschreibt (wohl davon ausgehend, daß die cpu tatsächlich mit 6,67 MHz getaktet war und er keinen Programmierfehler gemacht hat).

Obwohl wir unter den bisherigen Resultaten noch keinen Eintrag für einen DMV haben (die Programmversion für den DMV ist noch nicht geschrieben; da gibt es einige Probleme anderer Art (Aufsetzen/Konfigureren der ANSI-MsDos Version von TP3 auf einem "modernen" Rechner) und mir mein DMV zZt nicht zugänglich ist, um zügig voranzukommen und so nicht den Umweg über 33 Testversionen über das Forum nehmen zu müssen), lassen sich doch aus den bisherigen Ergebnissen mit 8088/V20 cpu vorab einige Informationen ziehen, die einen vorläufigen Rückschluß erlauben, ob die von Zander handgemessenen 12,8 sek für die JMPorgy zuviel sind oder nicht.

Das Cycles-Zählen sah so aus (lt. cpu manuals):

;
; NEC V20:                      8088:
; int 80h -> 50c / 2 bytes      71c
; iret    -> 39c / 1 byte       44c
; loop    -> 13c / 2 bytes      17c
;

Zu diesen Angaben der Anzahl der cycles muß aber noch bei int80 und loop jeweils 4c dazugezählt werden. Dies ist notwendig, da die Angaben zwar das Hereinholen von 1 weiteren opcode byte beinhalten, aber das jeweils 2. Byte der 2b-Befehle noch nachzuladen ist, bevor der Befehl ausgeführt werden kann.

Das macht in Summe für den

V20: 50+39+13 + 4 + 4 = 110 cycles

8088: 132 + 4+ 4 = 140 cycles

Man sieht als erstes, daß der V20 bei diesem Test deutlich besser aufgestellt ist. Alle anderen Faktoren gleich (MHz, Wait-States, ...)

sollte der 8088 rechnerisch eine um (140/110)-1 -> 27% längere Laufzeit haben.

THEORIE:

Die Abarbeitung dieser Cycles durch die beiden CPUs bei 4,77 MHz mit 500.000 Wiederholungen ergibt rechnerische Laufzeiten:

V20: 110 * 500.000 = 55.000.000 c --> 55 Mio / 4,77 Mhz = 11,53 sek

88: 140 * 500.000 = 70.000.000 c -> 70 Mio / 4,77 Mhz = 14,67 sek

Praxis:

Für den V20 (4,77 MHz) gibt es lt.Tabelle 2 Werte, aber da der eine Wert von einem Rechner mit S-RAM ist (kein refresh!!!) scheidet dieser

aus und als Vergleichswert gilt 12.955.569,500 usec.

Lt. Tabelle gibt es zwei 8088 (4,77 MHz) Einträge mit den Laufzeiten 15.117.788,442 und 15.166.749,118 usec.

Die liegen eng beieinander (gut so), der Mittelwert beträgt 15.142.268,78 usec

Ergebnis:

a) Der V20 ist in der Praxis um 1,4 Sekunden langsamer als lt. den Angaben im Manual. Das sind herzhafte 12 %.

b) Der 8088 ist um nur 0,5 Sek langsamer als er theoretisch sollte, das sind nur 3 %,

Das deutet zumindest in die Richtung, daß Zander's Interpretation seiner Handmessung überzogen war/ist.

Vielleicht sind ja die Zahlen im Manual des V20 zu optimistisch.

ABER: Er maß 12,8 Sekunden für den V20 bei 6,67 MHz.

Das ist soviel wie der Wert aus der Tabelle für den soeben besprochenen V20 bei 4,77 MHz - 12,96 Sekunden.

funkenzupfer

danke für aufschlüsselung!

Damit ich weiß was auf mich zukommt: Was werden denn (Daumen x Pi ) die jeweiligen Platinen kosten?

funkenzupfer

möchte mich gerne für k235plus und k0815 anmelden.

die beantwortung der frage ob k235plus + 512ram oder k235plus ohne ram + k0815 interessiert mich auch!

Kann da jemand vor-/nachteile erklären?

ich habe von zusammenbau/fertigstellen dieser dinge keine ahnung. da ist von gals und bausteinen die rede ... keine ahnung ...

ich bräuchte das set komplett (bis auf die gesockelten 8088/8087 chips, das schaffe ich schon zu besorgen und einzusetzen ...)

gibts jemanden im forum, der sich gegen honorierung diesen zusammenbau für mich annimmt?

PAW

derartige "synthetische" tests wie "jmp-orgy" decken schwächen einer cpu-architektur auf. genau das sieht man nier ja auch an der "effizienz"

(verbratene cpu-cycles während der ausführung). genau diese effizienz (niedrigerer wert = besser) im vergleich 2er cpus sagt einem, wie gut die MHz in Leistung (speed) umgesetzt werden.

ops/sec: ja, das ist sozusagen der inverse Wert der Runtime - Fahrzeit vs km/h bei einer Autofahrt - und bedeutet wie oft die routine in 1 sec ausgeführt werden kann.

ad interrupts deaktivieren:

es ist natürlich richtig, daß bei aktiven interrupts die testroutine alle 54 ms unterbrochen wird, um die systemzeit zu aktualisieren, und diese zeit der timer-interrupt-service-routine im meßergebnis drin ist. aber das macht insofern nichts, als genau diese situation "real world" verhalten widerspiegelt. dreht man die interrupts ab, dann würde übrigens eine Messung die über 54 ms hinausgeht unmöglich werden. denn wenn während der laufzeit die systemuhr aufgrund deaktivierter timer ISR nicht mehr aktualisiert wird, wie soll man dann einen zeitunterschied zwischen startzeit und endzeit feststellen, der über das auslesen des internen 8253 counters (startwert/endwert und differenzbildung) hinausgeht? Denn es würden ja die countertoks (alle 54,925ms) und eventuelle änderung des stundenzählers verunmglicht werden ..... Kurz gesagt: bei deaktiviertem timer-interrupt bleibt die Uhrzeit stehen (bis auf max zeitspanne von 54,9ms).

PAW, bitte herausfinden welche CPU sich im HP Rechner befindet. danke.

Hier die letzte Zusammenstellung aller Ergebnisse (mit Korrekturen wie gewünscht) inkl. der Ergebnisse aus dem anderen Forum.

Ich glaube unsere postings haben sich zeitlich überschnitten

ich habe eine aktualisierte tabelle von allen werten die hier im forum gepostet wurden veröffentlich (seite 4 fast ganz unten).

die ergebnisse vom anderen forum arbeite ich gerne ein, aber daß kann jetzt ein wenig dauern ... vielleicht erst morgen .

1ST1

gute Arbeit gemacht im anderen Forum!

* "ys": es müßte eigentlich ein "müh" zeichen sein, statt dem "y", damit es korrekt ist. das "'müh" ist ein "y" mit geradem Aufstrich links. Ich war zu faul mir daß im Ascii Zeichensatz zu suchen und habe einfach ein y genommen (abgesehen davon gibt es auf alten Terminal-Rechner wie zb dem DMV eigene Zeichensatztabellen je nach eingestelltem Ländercode ... Und so habe ich zur Vereinfachung ein y genommen.)

* "tofro": nein, ich bin DoPe

Damit die im anderen Forum auch was von der Zusammenstellung (siehe voriger post) haben -> gerne dort posten.

Und die Anmerkung zur "efficiency" spalte wäre eigentlich auch gut. Ich halte diese Werte für SEHR interessant, weil man daran so gut sehen kann,

wie die CPU-Architektur für die Aufgabe/Test geeignet ist. Man sehe sich nur die Werte vom P4 oder 486er an ... Aber auch die Unterschiede zwischen 8 vs 16 Bit Systemen ...

erstmal DANKE DANKE DANKE an alle !!!

HIer zusammengestellt alle bisheringen Ergebnisse. Es lassen sich viele interessante Dinge feststellen.

Ich möchte besonders auf die Spalte "Efficiency" hinweisen.

Die Zahl dort ist die Anzahl der CPU-Zyklen, die für die Ausführung der Testroutine "verbraten" wurden.

Diese Zahl setzt die Laufzeit in eine Art Verhältnis zur rohen CPU power (MHz) und gibt an, wie "effizient" die Mhz in Leistung umgesetzt wurden.

Je niedriger der Wert, desto "effizienter".

Den WDSPEED test kann ich auf dem 486er nicht vernünftig laufen lassen.

zum Einen ist er so schnell fertig daß mit der hand stoppen nicht möglich ist.

dann habe ich auch einen bildschirm mit seltsamer farbgebung und es werden punkte ausgegeben. die benutzung von bildschirmausgaben in das timing mit herein zu nehmen ist keine gute idee, es verzerrt das ergebnis da man ja reine speicherperformance messen möchte .

da der dmv mit 5 mhz läuft und der pc4i mit 4.77 sollte der dmv eine kürzere laufzeit haben, also umgekehrt zum obigen resultat. das deutet in die vermutete richtung, aber wie gesagt ist das ergebnis durch die laufende bildschirmausgabe nicht wirklich aussagekräftig im sinne unserer untersuchung.

1ST1

laß doch bitte den olimarck mit der NCP (No Co-Processor) Version des Programms laufen

download hier

funkenzupfer

eben weil es um den nachbau der k235 karte geht (die sogar zusätzlich 512 kb aufnehmenen soll) lasse ich zander sprechen.

ob man die schlechte memory-performance, welche nach zander am dmv vorliegt und von ihm - richtigerweise oder nicht - mit der k235 karte in verbindung bringt (siehe zitat) mit einer berücksichtigung beim nachbau umgehen kann weiß ich nicht.

ich kann nicht beurteilen, ob das was Zander herausgefundeen hat eine DMV Eigenschaft ist, die man "reparieren" kann, oder ob das hinzunehmen ist.

Mir geht es um den Teil, in der die Karte ins Spiel kommt:

Zitat

Dieser Baustein erzeugt ein Wartesignal, das als "readyp"

(Pin b10 an J107) auf dem Systembus liegt. Auf der 8088 Karte

wird dieses Signal über den Taktgenerator auf den ready input des

8088 geleitet und erzeugt dort zusätzliche Wartezeiten.

Alles anzeigen