Archiv verlassen und diese Seite im Standarddesign anzeigen : 1. IBM PC 8088 XT spielt Video im Vollbildmodus bei 30 fps in Farbe und mit Sound ab!
Und das auf einem Prozessor der einen Takt von nur 4,77 MHz hat! :eek:
Hier das Video:
Als Stream 265Kb MPEG4
http://www.archive.org/stream/8088CorruptionExplained/8088CorruptionExplained_NTSC_DVD_256kb.mp4
Zum Downloaden als MPEG2 in höchster Qualität
http://www.archive.org/download/8088CorruptionExplained/8088CorruptionExplained_NTSC_DVD.mpg
Oder wählt euer Format einfach selber:
http://www.archive.org/details/8088CorruptionExplained
Genauere Hintergrundinformationen:
http://www.oldskool.org/pc/8088_Corruption
http://www.archive.org/details/8088CorruptionExplained
Eine IMO sehr beeindruckende Leistung, was man aus so einem alten Rechner
noch alles herausholen kann.
Ich empfehle übrigens zum anschauen das MPEG2 Video in hoher Qualität.
Die Qualität der gezeigten Videos ist zwar sehr bescheiden, aber man kann durchaus was erkennen.
Wenn man allerdings die Hardware (8088 mit CGA Grafik, 40x25 Zeichen mit 2 Farben pro Zeichen) bedenkt ist das ganze echt verrückt.
Am meisten fasziniert hat mich die Idee A/V syncron zu halten. Die Soundkarte als Timer herzunehmen hat was :cool:
][immy
2007-11-19, 23:16:40
Ich empfehle übrigens zum anschauen das MPEG2 Video in hoher Qualität.
nunja, bei den videos habe ich in der kleinen version subjektiv ein besseres bild gesehen was die 8080XT videos betrifft ;)
nett, aber irgendwie auch ziemlich verrückt
Sowas schaffte auch ein C64 mit 64KB und 1Mhz.
Sowas schaffte auch ein C64 mit 64KB und 1Mhz.
Beleg?
Halte ich auch für unwahrscheinlich. Die Rechenleistung eines 8088 mit 4,77Mhz ist dann doch deutlich höher als die eines 6501 mit 1 Mhz.
Avalox
2007-11-20, 15:23:04
Sowas schaffte auch ein C64 mit 64KB und 1Mhz.
Der Meinung war ich eigentlich auch. Ich denke mal einen MPEG2 Videoplayer für den C64 gesehen zu haben. Aber auf die schnelle gefunden habe ich auch nichts.
Was beim XT noch ein Briefmarkengroßes Bild ist, ist beim C64 er dann schon ein Reisnagelkopf.
in diesem fall is die hauptbegrenzung ja nichtmal umbedingt die cpu sondern viel eher die cga grafik. wobei ich jetzt auch nich weiss wie leistungsfähig die c64 grafik im ggnsatz zu cga war.
in diesem fall is die hauptbegrenzung ja nichtmal umbedingt die cpu sondern viel eher die cga grafik. wobei ich jetzt auch nich weiss wie leistungsfähig die c64 grafik im ggnsatz zu cga war.
Na die c64 Grafik konnte immerhin schonmal 16 Farben aus einer Farbpallette von 64 Farben gleichzeitig darstellen.
Bei CGA war das auf 4 Farben begrenzt aus einer Farbpallette von nur 16 Farben.
Das bringt aber alles nichts, da die CPU des C64 mit nur 0,98 MHz getaktet war und nur über eine 6 Bit Ein-/Ausgabeanbindung verfügte.
Und so Grafikfähigkeiten wie Hardwarescrolling und Spriteverarbeitung sind in diesem Fall untauglich.
Das nächste Problem dürfte der winzige Speicher von nur 64 Byte sein.
Im Prinzip hat ein C64 gegen einen 8088 XT keine Chance.
Ganz anders sieht es beim Amiga 500 aus, der könnte so etwas durchaus packen.
Bufi@work
2007-11-22, 13:28:10
Das nächste Problem dürfte der winzige Speicher von nur 64 Byte sein.
Sollen wohl eher 64kByte sein... :)
Avalox
2007-11-22, 14:00:08
Bankswitching ermöglicht ja weit mehr Speicher anzusprechen, als eigentlich adressierbar ist.
cga schaffte afaik auch mit geringer auflösung und trickserei 16 gleichzeitig darstellbare farben
MrMostar
2007-11-22, 20:42:52
Na die c64 Grafik konnte immerhin schonmal 16 Farben aus einer Farbpallette von 64 Farben gleichzeitig darstellen.
Nö, der 64er kann 2 bzw. 4 Farben aus einer fixen 16 Farbenpalette darstellen(Hires/lowres), man konnte durch Tricks mehr Farben erreichen, durch Tauschen von 2 Palettenfarben pro 8x8 Grafikblock, Interruptprogrammierung, sowie Spriteüberlagerung, ich hab die Register des Grafikchips selber mal in assembler gequält... :wink:
The Jackal
2007-11-24, 22:57:34
Das gnaze zeigt uns nur eines.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?
Es wird viel zu sorglos mit der Rechenleistung umgegangen und ich bin der festen Überzeugung die neuem Spiele sind das beste Beispiel dafür. Siehe Crysis.
Der gezeigte Rechner da ist ja von 1981 und da läuft Mpeg, wo ein PII 233 MHz schon probleme hat. Was kann man aus heutingen Rechnern alles rausholen wenn sich die Firmen wie M$ mal anstrengen würden?
Das gnaze zeigt uns nur eines.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?
Nein, das ist Unfug.
Die Kriterien von hochwertigem Programmcode sind heutzutage andere als früher.
Heute ist ein Programmcode hochwertig, wenn dessen Design (also Klassendiagramme usw.) übersichtlich und leicht erweiterbar ist und der Code leicht zu warten ist.
Früher war ein Programmcode hochwertig, wenn er sparsam war und
noch in extrem wenig Speicherplatz reingeqeutscht werden konnte.
Falls es Spagetthi Code war, war das nicht so schlimm, solange er lief.
Fazit:
Kein Mensch könnte oder würde die 2. Variante für heutige komplexe Programme finanzieren und bezahlen wollen.
Das ist einfach utopisch, deswegen wird das auch nicht mehr gemacht.
Andere Dinge stehen im Vordergrund.
Der gezeigte Rechner da ist ja von 1981 und da läuft Mpeg, wo ein PII 233 MHz schon probleme hat.
Da läuft kein MPEG. Das Video ist so von einem modernen Rechner vorverarbeitet dass es der gezeigte Rechner einfach nur noch in den CGA-Framebuffer schaufeln muss (im 40x25 Textmodus mit 16 Farben).
TheGoD
2007-11-25, 08:03:39
Das gnaze zeigt uns nur eines.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?
Es wird viel zu sorglos mit der Rechenleistung umgegangen und ich bin der festen Überzeugung die neuem Spiele sind das beste Beispiel dafür. Siehe Crysis.
Der gezeigte Rechner da ist ja von 1981 und da läuft Mpeg, wo ein PII 233 MHz schon probleme hat. Was kann man aus heutingen Rechnern alles rausholen wenn sich die Firmen wie M$ mal anstrengen würden?
Hauptsache mal über Crysis gemerkert weil dein Rechner zu schwach dafür ist...:rolleyes:
€dit: Das war durchaus auf die x850xt 256 bezogen. Oder denkst du dein Q6600 sollte die Grafik berechnen?
The Jackal
2007-11-25, 17:06:23
Es gab ein Shooter spiel von einer kleinen Softwareschmiede mit grafischen Deteillevel von Quake 2. Nur das das ganze Game 4 MB groß war. Haben sehr viel mit Strukturen gearbeitet die auf einem Algorithmus basieren.
Ich habe die Quelle nicht mehr. Ist auch schon min 2 Jahre her.
@TheGoD
Erst fragen was ich für ein Rechner habe oder in der Sign gucken, dann erst spammen.
du meinst aber nicht kkrieger? das ist übrigens 96kb groß und braucht min. 1ghz und 512mb ram oder so...
The Jackal
2007-11-25, 22:04:03
Jo das war es. Genauso kann man auch in andere richtung programieren, das man möglichst wenig Rechenpower braucht.
@ The Jackal
Du hast von Software Entwicklung keine Ahnung, das ist das Problem.
KKrieger ist ne nette Demo aus der Demoszene, das wars auch schon,
aus wirtschaftlicher Sicht kann man so keine Spieleentwicklung betreiben.
Aber wer weiß, vielleicht wird genau so Duke Nukem Forever programmiert,
das würde dann einiges erklären. :D
Das gnaze zeigt uns nur eines.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?
Es wird viel zu sorglos mit der Rechenleistung umgegangen und ich bin der festen Überzeugung die neuem Spiele sind das beste Beispiel dafür. Siehe Crysis.Das hat damit doch gar nichts zu tun. Der Player auf dem 8088 ist ziemlich simpel. Die Umwandlung des Videos wurde nicht auf einem 8088 ausgeführt, sondern auf einem "richtigen" PC – und die besten Schriftzeichen und Farbkombinationen wurden Buchstabe für Buchstabe mittels kompletter Suche gefunden. Nicht elegant, diese Brute-Force-Methode.
Der gezeigte Rechner da ist ja von 1981 und da läuft Mpeg, wo ein PII 233 MHz schon probleme hat. Was kann man aus heutingen Rechnern alles rausholen wenn sich die Firmen wie M$ mal anstrengen würden?Die strengen sich doch an. Auf dem XT läuft kein MPEG, sondern es werden unkomprimierte Daten in den Bildschirmspeicher geladen, welcher im niedrigauflösenden Textmodus läuft.
Wenn man solche Demos wie hier besprochen programmiert, hat man genau ein Zielsystem. Der PC ist aber eine modulare Plattform. Da besteht gar nicht die Möglichkeit, sich bei jeder einzelnen Hardwarekomponente auf eine bestimmte Performance verlassen zu können.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?Wie grottenschlecht sind unsere Auswahlkriterien?
Das gnaze zeigt uns nur eines.
Wie grotten schlecht ist den die Software programiert die wie alle jeden Tag aufs neue nutzen?
Es wird viel zu sorglos mit der Rechenleistung umgegangen und ich bin der festen Überzeugung die neuem Spiele sind das beste Beispiel dafür. Siehe Crysis.
Der gezeigte Rechner da ist ja von 1981 und da läuft Mpeg, wo ein PII 233 MHz schon probleme hat. Was kann man aus heutingen Rechnern alles rausholen wenn sich die Firmen wie M$ mal anstrengen würden?
Hier, das ist das richtige OS für dich:
http://www.menuetos.de/
Hier, das ist das richtige OS für dich:
http://www.menuetos.de/man benutzt nicht betriebssysteme sondern programme.
Shink
2007-12-01, 17:10:20
Hier, das ist das richtige OS für dich:
http://www.menuetos.de/
MenuetOS ist nett, klein und in Assembler geschrieben, aber ressourcenschonend ist es deswegen noch lange nicht.
MenuetOS ist nett, klein und in Assembler geschrieben, aber ressourcenschonend ist es deswegen noch lange nicht.
Warum denn nicht?
Nichts ist effizienter und resourcenschonender als guter von Hand geschriebender Assemblercode.
Natürlich vorausgesetzt der Mensch hat Ahnung und überbeitet den Compiler.
Warum denn nicht?
Nichts ist effizienter und resourcenschonender als guter von Hand geschriebender Assemblercode.Nur solange man auf derselben Plattform bleibt. Da die PC-Industrie aber im ständigen Wandel ist, und ständiges Neuschreiben oder anpassen des Assembler-Codes extrem zeitaufwändig wäre, würde ich nicht davon sprechen dass er "effizient" ist.
Neomi
2007-12-01, 22:27:04
Nichts ist effizienter und resourcenschonender als guter von Hand geschriebender Assemblercode.
Natürlich vorausgesetzt der Mensch hat Ahnung und überbeitet den Compiler.
Was du da gerade in anderem Wortlaut gesagt hast, ist, daß handgeschriebener Assemblercode besser ist, wenn der Mensch besseren Code erzeugt als der Compiler. Genauso kann man sagen, der Compiler ist besser, natürlich vorausgesetzt er erzeugt besseren Code. Kurz: X trifft zu, wenn X zutrifft, eine Nullaussage.
Auch die besten Compiler greifen teilweise richtig ins Klo, daß einen beim Blick in den disassemblierten Code das Entsetzen packt. Allerdings haben gute Compiler auch derart "kranke" Optimierungen drauf, daß selbst der beste Programmierer (den imaginären perfekten Programmierer gibt es nicht) nicht mithalten kann. Abgesehen davon gibt es auch keinen perfekten Code für die meisten Funktionen. Beim x86 z.B. gibt es viele verschiedene CPUs, die jeweils unterschiedliche Instruktionsfolgen besser verdauen können. Und auch wenn man sich auf eine einzige mögliche CPU beschränken kann, wie es bei Konsolen der Fall ist, gibt es für die meisten Dinge keinen perfekten Code, weil je nach den gerade zu verarbeitenden Daten (und Cacheinhalt, ...) mal dieser und mal jener Code schneller ist.
Wenn man wirklich performanten und guten Code schreiben will, dann sollte man zwar Assembler lesen können, aber keine Programme in Assembler schreiben. Lesen deshalb, weil man dem Compiler gut unter die Arme greifen kann, wenn man sich Disassemblies ansieht und Optimierungspotential erkennen kann, was man dann mit diversen Umstellungen im Code evtl. (leider nicht immer) ausschöpfen kann. Guter Code schließt aber handgeschriebenen Assembler aus, weil guter Code wiederverwendbar, portabel und einfach wartbar sein sollte. Assembler als Sprache für geschriebenen Programmcode ist einfach nicht praktikabel, wenn es sich nicht auf hier und da mal plattformabhängigen Inline-Assembler beschränkt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.