Computerrätsel 3
Ja, der erste Computer mit einem 16-Bit-Prozessor, der unter 1.000 Mark kostete war der TI 99, oder um es genauer zu sagen der Ti 99/4a (es gab etwas später auch einen Ti 99/2, als Billigversion) und ein Ti 99/8 System das leistungsfähiger sein sollte, stand kurz vor der Markteinführung, als sich Ti aus dem Heimcomputermarkt zurückzog.
Ich selbst habe einen Ti 99/4a besessen, bzw. habe jetzt wieder einen, nachdem mir ein treuer Website Besucher einen gestiftet hat. Er funktioniert auch noch, nur das Bild ist nicht mehr besonders gut.
Was mir auffiel, auch im Vergleich zu meinem nächsten 8-Bitter (einem CPC 464) ist seine Langsamkeit. Er war 3-4 Mal langsamer als ein VC20 oder C64. Woran lag das, wenn er doch einen 16-Bit-Prozessor einsetzte?
Nun es wurde auf die komische Architektur des Ti 99 zurückgeführt. Der Hauptprozessor TMS 9900 adressierte 32 KWorte RAM (64 KBytes). Er hatte aber nur drei Register: das Statusregister (Flagregister), den Programm Counter und einen Workspace Pointer. Da wir hier einige Assembler-Kundige haben, wird nun etwas auffallen – es gibt keinen Akkumulator oder sonstige Rechenregister. Ti ging davon aus, das RAM schnell genug war, um als Registerersatz zu fungieren: Der Workspacepointer zeigte auf einen RAM-Bereich, der als 16 Register genutzt werden konnte. Wem das nicht reichte, der konnte einen anderen Bereich auswählen.
Leider wurde RAM nicht so viel schneller wie von Ti noch 1976 vorgesehen und so bremsten schon mal Wait States den Prozessor aus. Noch schlimmer: Die 16 KByte RAM die im Ti 99/4A verbaut waren gehörten nicht dem Prozessor, sondern dem Video Display Prozessor 9928. Wenn der Prozessor auf das RAM zugreifen konnte, dann ging das nur adressseriell. Es gab eine 32 KByte RAM Erweiterung für den Ti 99/4A, die direkt angesprochen werden konnte und ein 4-KByte-Mini Memory Modul. Für beide war aber ein weiteres Modul, Extended Basic nötig.
Das Extended Basic war keine Erweiterung des Basic, sondern ersetzte es, denn das BASIC hatte noch eine andere unangenehme Eigenschaft: Es war doppelt interpretiert. Das BASIC Interpreter war nicht in Maschinensprache geschrieben, sondern einer weiteren interpretierten Programmiersprache namens GPL. Alleine dadurch wurde das Extended BASIC zwei bis dreimal schneller und lag so gleichauf mit anderen Heimcomputern. Das BASIC war auch deswegen langsam, weil es mit 16 Stellen Genauigkeit rechnete – andere Rechner erlaubten die Wahl niedriger Genauigkeit oder erreichten maximal 14 Stellen.
Ich habe früher geschrieben, dass der Prozessor TMS 9900 etwa gleich schnell wie der Intel 8086 war, muss mich aber nach Lektüre einer alten ct‘ korrigieren. Das gilt für das Nachfolgeexemplar TMS 9995. Dieser hatte auch 256 Bytes internes RAM um den Nachteil des langsamen RAM’s zu umgehen. Für eine 16-Bit-Addition braucht der TMS 9900 (mit Laden der Daten und Speichern insgesamt 52 Taktzyklen, ein Z80 dagegen nur 45. Er war daher schon mit den 8-Bittern vergleichbar. Der 9995 war dreimal schneller, obwohl er aus Kostengründen nur einen 8-Bit-Datenbus einsetzte (der TMS 9900 dagegen 16 Bit). Er war schneller als der 8086 und in etwa gleichauf mit dem 80186 (der höher getakteten und etwas schnelleren Version der 8086).
So, nun das neue Rätsel: Wessen Motto war „Business is like War“? (wir reden natürlich von bekannten Gestalten der frühen PC Geschichte)
Das stammt von Jack Tramiel, dem Gründer von Commodore. Ein Mann mit Ellenbogenmentalität.
War wahrscheinlich auch vom 2. Weltkrieg geprägt, wie viele seiner Altersgenossen.
Zur Rechengeschwindigkeit:
Ich bin mir jetzt nicht ganz sicher, und habe die Nachschlagewerke auch nicht Griffbereit im Regal, (sondern in Kisten irgendwo im Keller versteckt,) aber ich glaube der 6502 bzw. 6510 im C64 kam da mit noch weniger Taktzyklen aus, obwohl er dabei zwei 8-Bit additionen durchführen muss, weil er keine 16-Bit-Register hat.
Die Rechenroutine sieht dann etwa so aus:
LDA $zahl1_lo ; Lo-Byte der ersten Zahl in den Akku holen,
ADC $zahl2_lo ; Addiere LoByte der zweiten Zahl
STA $erg_lo ; Ergebnis merken
LDA $zahl1_hi ; Hi-Byte der ersten Zahl in den Akku holen,
ADC $zahl2_hi ; Addiere HiByte der zweiten Zahl
STA $erg_hi ; Ergbniss merken
BCS überlauf ; Überlauf, d.h. Ergebniss hat 17 Bit
$zahl1_lo, $zahl1_hi, $zahl2_lo, $zahl2_hi, $erg_lo und $erg_hi bezeichnen dabei jeweils die Adressen, an denen die Zahlen im Speicher liegen. „überlauf“ ist ein Programmlabel, in diesem Fall ein Sprungziel, da BCS ein bedingter Sprungbefehl ist, der bei einem Überlauf ausgeführt wird.
Soweit ich mich erinnere, benötigen die Befehle ca. 3 bis 5 Taktzyklen, d.h. die Lade-, Rechen- und Speicherbefehle brauchen maximal 30 Taktzyklen, wieviele der Sprungbefehl braucht, weis ich gerade nicht, meine aber 3.
Es könnte allerdings sein, das der 6502 trotzdem langsamer ist, weil er in der Regel nur mit 1 MHz getaktet wird, und nicht mit 4 oder 5, wie beispielsweise der Z80. Um das festzustellen, müsste ein Benchmarktest her, der die Prozessoren ein bisschen Rechnen lässt…
Zu Anfang fehlt noch ein CLC, damit ein zufällig gesetztes Carry-Bit nicht das Ergebnis um 1 erhöht. Die Speicherzugriffe sind unterschiedlich schnell, je nachdem ob die Zeropage addressiert wird oder der restliche Speicher. Man kommt dann auf ca. 30-40 Taktzyklen.
Das C64-Basic hatte übrigens eine traurige Eigenheit, die es unnötig langsam machte: man konnte zwar Ganzzahlvariablen benutzen, die wurden bei jeder Rechnung intern aber zuerst in Fließkomma und wieder zurück gewandelt, was sie vollkommen nutzlos machte.
Beim Z80 wäre es
LD DE,(nnnn) ; 20 Takte
LD HL,(nnnn) ; 16 Takte
ADD HL,DE ; 11 Takte
LD (nnnn),HL ; 16 Takte
(war eben zu 16 Bit Ops fähig)
Geschwindigkeitsmäßig gibt es sich kaum was, da ein Z80 meist mit 3-4 MHz getaktet war, was die höhere Taktzahl meist kompensierte (ein Z80 mit 4 MHZ war so schnell wie ein 6502 mit 2). In der Praxis spielte z.b. bei den BASIC Interpretern oft deren Implementation eine Rolle. Ich sollte da mal eine alte Tabelle aus der ct publizieren, da sieht man die Unterschiede bei Rechnern mit derselben CPU und fast gleicher Geschwindigkeit recht deutlich.
Beim Atari-Basic wurde konsequenterweise gleich ganz auf Integer-Zahlen verzichtet, da gab es generell nur 6 Byte Gleitkommazahlen.
Die Hauptbremse bei den Heimcomputern war allerdings nicht der niedrige CPU-Takt, sondern die Grafik. Wie auch heute wieder bei Office- oder besser gesagt Billig-PCs wurde der normale RAM als Bildspeicher verwendet. Um ein flackerfreies Bild zu erhalten, mußte die CPU warten solange etwas ausgegeben wurde. Praktisch blieb da also nur die Zeit für den Vertikal- und Horizontal-Rücklauf, wo die CPU überhaupt mal zum Zuge kommen durfte. Und das sind eben nur wenige Prozent der Gesamtzeit.
Theoretisch hätte man die Geräte wesentlich schneller machen können, wenn sie mit extra Grafikspeicher ausgestattet wären, der nur wenn wirklich Daten ausgegeben werden mit dem CPU-Bus verbunden wird. Bei den damaligen Bauteilpreisen wären die Kisten dann allerdings deutlich teurer geworden. Deshalb war das in Heimcomputern nicht üblich.
Beim C64 wurden die Taktlücken benutzt, der Prozessor wurde normalerweise nicht ausgebremst. Der Videochip hat ihm nur gelegentlich ein paar Taktzyklen geklaut, wenn er viel zu tun hatte, insbesondere bei der Spritedarstellung. Die Fastloader haben die zeitraubende Synchronisation vereinfacht, in dem die Sende- und Empfangsroutinen genau aufeinander abgestimmte Taktzyklen hatten. Deshalb wurde für die Fastloader der Bildschirm immer abgeschaltet oder auf schnell wechselnde Hintergrundfarbe reduziert, damit der Videochip die Synchronisation nicht durcheinanderbringen konnte.
@Arne: Stimmt, den CLC- Befehl hab ich vergessen. Und das mit der Zeropage ist mir beim schreiben auch eingefallen, aber da wollte ich dann erst mal nicht mehr drauf eingehen, weil das 6502-spezifisch ist. Denn soweit ich weis, kennen andere Prozessoren keine Zeropage in dieser Form.
Und das der Basicinterpreter intern nur mit Fliesspunktzahlen gearbeitet hat, ist ein Manko, das ja auch damals schon kritisiert wurde. Das ist aber auch beim Basic 7.0 des 128ers nicht anders. Das kennt zwar auch Integerzahlen, wandelt die zum Rechnen aber auch erst ins Fliesspunktformat um. – Das war dann auch ein Grund, warum ich in Basicprogrammen nie Integerzahlen verwendet habe.
@Bernd: So eine Tabelle wäre interessant. Die Frage ist bloss, wie das mit den Urheberrechten aussieht. Obwohl ich annehme, dass die als Zitat durchgehen kann.
Und was die Grafik angeht: Der 80-Zeichen-Controller vom C-128 hatte einen eigenen 64K grossen Bildschirmspeicher. Damit war es sogar möglich zwei separate Bildschirmseiten zu verwalten, und je nach Bedarf dazwischen hin und her zu schalten. Allerdings war es relativ umständlich, auf diesen Speicher zuzugreifen, und nur in Assembler in akzeptabler Geschwindigkeit möglich. – Vermutlich war das auch ein Grund, warum der 80-Zeichenmodus nur so stiefmütterlich benutzt wurde…