Computernerds unter sich - Der Computerschwampf

[Airlag]

vor 15 Stunden schrieb dabba:

Ist das überhaupt ein richtiger Emulator? Sieht mehr als wie ein Aparillo, der RAM und Videoausgabe an die vorhandene Intel-CPU durchschleift. OK, die Video-Standards müssen emuliert werden.

Apropos Emulation: Neues von der Windows-für-ARM-Front. Die ARM-Variante von Windows wird in der Lage sein, 32-bittige x86-Windows-Programme zu emulieren.
https://stadt-bremerhaven.de/windows-10-on-arm-microsoft-gibt-versehentlich-die-einschraenkungen-bekannt/
Das Thema finde ich durchaus spannend. Das Smartphone dürfte in Verbindung mit einer Docking-Station mittelfristig so manchen Desktop-PC ablösen.

Richtig, die damaligen 'Emulatoren' waren in Wirklichkeit Bridge-Karten auf denen die fehlende Hardware des Fremdsystems steckte.
Emulation heißt für mich, die vorhandene Hardware tut so, als wäre sie eine andere.

Ich hatte auch eine PC-Karte für den Amiga 2000. Die wurde einfach in einen Steckkarten-Slot gesteckt. Andere Karten (wie die oben gezeigte) wurden in den Prozessor-Sockel gesteckt.

Mit meiner Karte konnte man beide Betriebssysteme parallel betreiben. Allerdings gab es dann Probleme mit der Darstellung am Bildschirm, weil der Amiga die Grafikkarte für die PC-Seite darstellte. Das hätte man besser lösen können.

Bearbeitet 20. Februar 2018 von Airlag

[Abd al Rahman]

@Airlag Das Problem des C64 war der 6510. Apple setzte auf den 6502, was in späteren Jahren genutzt werden konnte um die schnelleren Versionen dieses Prozessors zu verbauen. Zudem wuchs der Ram des Apple II mit der Zeit. 

[Solwac]

vor 53 Minuten schrieb Widukind:

Wie sollte denn ein "echter" Hardware-Emulator deiner Meinung nach aussehen?

Der Unterschied liegt zwischen CPU-Emulator (viel Aufwand für wenig Ertrag, da kann man einfach die Original-CPU nehmen) und einem Computer-Emulator, der dem Programm BIOS, IO-Ports, Spezialbausteine usw. vorgaukelt.

[Solwac]

vor 41 Minuten schrieb Abd al Rahman:

@Airlag Das Problem des C64 war der 6510. Apple setzte auf den 6502, was in späteren Jahren genutzt werden konnte um die schnelleren Versionen dieses Prozessors zu verbauen. Zudem wuchs der Ram des Apple II mit der Zeit. 

Das Problem sind eher die Spezialchips gewesen. Apple hatte eine offene Struktur, was von Anfang an von den Programmierern angenommen wurde. Dort wurde also etwas kompatibler mit späteren Aufrüstungen umgegangen. Ein Programm für 48 KB lief deshalb noch nach der Aufrüstung auf 64 KB.

 

[Airlag]

vor 3 Stunden schrieb Abd al Rahman:

@Airlag Das Problem des C64 war der 6510. Apple setzte auf den 6502, was in späteren Jahren genutzt werden konnte um die schnelleren Versionen dieses Prozessors zu verbauen. Zudem wuchs der Ram des Apple II mit der Zeit. 

Hat der RAM im Gehäuse gerammelt und Junge gekriegt?

Ein Apple II hatte meines Wissens nie mehr als 32 KB RAM und 16 KB ROM. Der Apple IIe hatte bis zu 1 MB RAM bei 16 Adressleitungen. Apple hat ein anderes Bankswitching verwendet als Commodore im C=64. Programme für Rechner mit Bankswitching zu schreiben war eine Qual. Multitasking verbot sich fast von selbst und Interupt-Programmierung führten bei Bankswitching zu Problemen.

Deshalb setzte Äppelgenauso wie Commodore bei späteren Rechnern auf den M68000, welcher ein vollwertiger 16 Bit Prozessor ist mit intern 32 Bit Adressbus und extern immerhin 24 Bit Adressbus verfügte. Damit ließen sich immerhin 16 MB Speicher direkt adressieren. Was erst mal nach Verschwendung klingt (Befehlssatz mit 4 Byte langen Adressen aber physikalisch nur 3 Bytes genutzt) stellte sich im Nachhinein als Vorausschauend heraus, weil beim Wechsel auf den nächsten Prozessor mit vollen 32 Bit Adressraum liefen die alten Programme ohne Probleme.

Zur selben Zeit hantierte die DOS-Welt mit Intels 8086-Prozessor, der zwar ein 16 Bit Prozessor ist, aber intern und extern nur 16 Bit lange Adressen verwendet. Über ein Prozessorregister von dem 4 Bits als Adressleitungen ausgeleitet wurden, weitere 4 jedoch die obersten Adress-Bits übersteuerten, wurde ein Paging realisiert. Diese Speicherseiten überlappten sich allerdings. Was das für die Programme bedeutete kann ich mir als Programmierer lebhaft vorstellen.

Nach dem 68000 haben Commodore und Äppel auf die Nachfolgeprozessoren gesetzt. Ab dem 68020 mit vollem 32 bit Adressraum für 4 GB Speicher.

Falls du andere Informationen hast, her damit

Bearbeitet 20. Februar 2018 von Airlag

[Solwac]

vor 3 Minuten schrieb Airlag:

Was erst mal nach Verschwendung klingt (Befehlssatz mit 4 Byte langen Adressen aber physikalisch nur 3 Bytes genutzt) stellte sich im Nachhinein als Vorausschauend heraus, weil beim Wechsel auf den nächsten Prozessor mit vollen 32 Bit Adressraum liefen die alten Programme ohne Probleme.

Gerade beim Mac haben die Programmierer hier teures Lehrgeld bezahlt. Viele haben das eine Byte für anderes verwendet und deren Programme liefen dann nicht mehr...

[Airlag]

Gerade eben schrieb Solwac:

Gerade beim Mac haben die Programmierer hier teures Lehrgeld bezahlt. Viele haben das eine Byte für anderes verwendet und deren Programme liefen dann nicht mehr...

Daten verstecken in (scheinbar) ungenutzten Bits, das ist ja böse!

So was tut man nicht, wenn man sich mit etwas Fantasie die Entwicklung seines Lieblings-Spielzeuges vorstellen kann 

Aber keine Sorge, auf dem C=64 haben einige Programmierer einen ganzen Schattenbefehlssatz illegaler Befehle verwendet, der durch das Layout des Prozessors entstand, aber nicht beabsichtigt war und dessen Funktion sich mit jeder Layout-Änderung verändern konnte. (ich habe einen Debugger/Single-Step-Tracer für die C=64 geschrieben, der diese illegalen Befehle auswertete).
Bei späteren Prozessorgenerationen (ab 16 Bit) landeten solche illegalen Befehle in Traps.

[Abd al Rahman]

@Airlag Der Speicher des II war erweiterbar. 

[Gast]

vor 7 Stunden schrieb Airlag:

Hat der RAM im Gehäuse gerammelt und Junge gekriegt?

Ein Apple II hatte meines Wissens nie mehr als 32 KB RAM und 16 KB ROM. Der Apple IIe hatte bis zu 1 MB RAM bei 16 Adressleitungen. Apple hat ein anderes Bankswitching verwendet als Commodore im C=64. Programme für Rechner mit Bankswitching zu schreiben war eine Qual. Multitasking verbot sich fast von selbst und Interupt-Programmierung führten bei Bankswitching zu Problemen.

...

Falls du andere Informationen hast, her damit

Apple II, erste Generation konnte bereits 64KB adressieren. MM I/O war 4KB groß, das eingeblendete ROM 12KB (10KB Basic Interpreter, 2KB das eigentliche OS) - blieben ohne weitere Maßnahmen maximal 48KB RAM zur freien Verfügung. In der ersten Generation wurden maximal 48KB RAM verbaut (1977 sündhaft teuer). Bank Switching kam erst später dazu, auf einer Erweiterungskarte, die gleich 16KB mitbrachte.

Kurze Zusammenfassung: A Trip down Memory Lane (Ihhh, sogar Double Switching notwendig, hatte ich nicht mehr auf dem Schirm).

Bearbeitet 20. Februar 2018 von Gast

[Airlag]

wie ich bereits schrieb, Programme schreiben für Rechner mit Bankswitching war eine Qual. Du wechselst die Bank und dein Programm (das liegt ja auch nur im Speicher) ist weg.

[metallian1]

Am 2/19/2018 um 11:33 schrieb dabba:

Jaja, Ihr habt damals alle noch die Maschinensprache mit der Bastelschere in die Lochkarten gesäbelt.

Du wirst lachen, aber ich habe wirklich noch Lochkarten verwendet.

Und 80 Spalten Papier zum Schreiben von Cobol Code. Da wurde nicht gleich in die Entwicklungsumgebung gehackert. Da hat man sich vorher auf Papier Gedanken gemacht..., Ok, das war 91 auf CTM mittlerer Datentechnik.

[Gast]

Neues vom Turing-Test: https://youtu.be/bd1mEm2Fy08

[dabba]

Rotozoomer, Sprites und 1024 Farben gleichzeitig - auf einem IBM-PC von 1981 mit 8088-CPU, CGA-Grafikkarte und 4,77 MHz Taktfrequenz

Ja, das geht.

Für die Nicht-PCler unter uns: Eigentlich kann CGA in "erträglichen" Grafik-Auflösungen nur vier Farben gleichzeitig.

Bearbeitet 3. November 2018 von dabba

[Toro]

Und es gibt sie, handgeschmiedete 7- Segment Anzeigen.

[Airlag]

Ich bin über ein kniffliges Problem gestolpert:

Wie speichert man in einer Undo-History einen Sortierbefehl möglichst platzsparend? Sortieren ist nicht so ohne weiteres reversibel und die bearbeitete Datenmenge kann groß sein.

Ich würde spontan eine Index-Liste nehmen, in der die Indizes der Datenzeilen vor der Sortierung abgelegt werden.

Kennt jemand eine bessere und platzsparendere Lösung?

[Lukarnam]

vor 20 Stunden schrieb Airlag:

Ich bin über ein kniffliges Problem gestolpert:

Wie speichert man in einer Undo-History einen Sortierbefehl möglichst platzsparend? Sortieren ist nicht so ohne weiteres reversibel und die bearbeitete Datenmenge kann groß sein.

Ich würde spontan eine Index-Liste nehmen, in der die Indizes der Datenzeilen vor der Sortierung abgelegt werden.

Kennt jemand eine bessere und platzsparendere Lösung?

Soll das Ergebnis des Sortiervorgangs abgespeichert werden, oder handelt es sich dabei "nur" eine anders geordnete Darstellung, eine vorübergehend "Ansicht", einer sonst (beliebig) persistent gespeicherten Liste?

Im Falle der "Ansicht" benötigst Du vermutlich gar kein "Undo". (Ansichten sind nicht persistent)

Im Falle der gewünschten "Persistenz" wird es - vor allem für lange Listen - hässlicher. Aber Speicher kostet nix, nur die Zugriffszeiten.

Bearbeitet 9. November 2018 von Lukarnam

[Gast]

vor 22 Stunden schrieb Airlag:

Ich bin über ein kniffliges Problem gestolpert:

Wie speichert man in einer Undo-History einen Sortierbefehl möglichst platzsparend? Sortieren ist nicht so ohne weiteres reversibel und die bearbeitete Datenmenge kann groß sein.

Ich würde spontan eine Index-Liste nehmen, in der die Indizes der Datenzeilen vor der Sortierung abgelegt werden.

Kennt jemand eine bessere und platzsparendere Lösung?

Ist die Sortierfunktion eine Black-Box aus Sicht der Undo-Funktion (bzw. Command-Managers)? Falls nein, könnten u. U. die notwendigen Verschiebungen effizient gespeichert werden (effizient heißt, platzsparend und je nach Sortier-Funktionalität liegen diese Informationen bereits vor, und müssen nicht ermittelt werden, der worst case ist halt blöd). Für die notwendigen Verschiebungen lässt sich dann einfach das Inverse bilden.

[Airlag]

vor 2 Stunden schrieb Lukarnam:

Soll das Ergebnis des Sortiervorgangs abgespeichert werden, oder handelt es sich dabei "nur" eine anders geordnete Darstellung, eine vorübergehend "Ansicht", einer sonst (beliebig) persistent gespeicherten Liste?

Im Falle der "Ansicht" benötigst Du vermutlich gar kein "Undo". (Ansichten sind nicht persistent)

Im Falle der gewünschten "Persistenz" wird es - vor allem für lange Listen - hässlicher. Aber Speicher kostet nix, nur die Zugriffszeiten.

Zielsetzung ist, ein Undo zu ermöglichen. Die Sortierung soll tatsächlich auf die Datentabelle ausgeführt werden.

Ich habe schon darüber nachgedacht, die Ausgabe und andere Zugriffe grundsätzlich über eine Indextabelle zu leiten. Sortierung wäre dann immer nur eine alternative Indextabelle. Datensätze müssten nicht hin und her kopiert werden.

[Airlag]

vor 2 Minuten schrieb Curilias:

Ist die Sortierfunktion eine Black-Box aus Sicht der Undo-Funktion (bzw. Command-Managers)? Falls nein, könnten u. U. die notwendigen Verschiebungen effizient gespeichert werden (effizient heißt, platzsparend und je nach Sortier-Funktionalität liegen diese Informationen bereits vor, und müssen nicht ermittelt werden, der worst case ist halt blöd). Für die notwendigen Verschiebungen lässt sich dann einfach das Inverse bilden.

Die Invertierung einer Sortier-Funktion funktioniert nur, wenn vorher auch eine definierte Sortierung vor lag - glaube ich.

Die Sortier-Funktion habe ich unter Kontrolle, ich kann mir also merken, wohin Zeile x verschoben wird - was ich als Indextabelle bezeichne. Ich wollte wissen, ob jemand eine noch sparsamere Methode kennt als pro Datenzeile eine Integer abzuspeichern.

[Gast]

Bei der Eingabe in die Sortierfunktion ist die Position der Elemente bekannt, sonst macht ein Undo keinen Sinn (oder ich verstehe dich noch falsch).

Beispiel Ausgangslage:
1 Zwetschge
2 Banane
3 Dattel
4 Kirsche
5 Orange
6 Pfirsich
7 Aprikose

Wird lexikalisch sortiert, notwendiger Tausch: 1<>7, Undo dazu: 7<>1

Du sparst, wenn bereits gut vorsortiert ist.

Ansonsten müsstest du weitere Infos zum Kontext preisgeben. Datenbanksystem? Temporale Datenhaltung?

[Airlag]

@Curilias thx, Der Gedanke, zusammen mit dem Beispiel sieht sehr sparsam aus.

...

Ich habe mal ein paar Szenarien durchgespielt. Abgesehen von einem Ausnahmefall wie dem Beispiel ist der günstige Fall für deinen Vorschlag eine Umkehrung der Sortier-Richtung A->Z zu Z->A, Dann kommt man mit n/2 Operationen aus (n = Länge der zu sortierenden Liste)
Schon bei folgender Konstellation, die wohl häufiger vor kommen wird, sieht es katastrophal schlechter aus
1 Aprikose
2 Dattel
3 Kirsche
4 Orange
5 Pfirsich
6 Zwetschge
7 Banane
Normal wird also irgendwas zwischen n/2 und n-1 Operationen sein, für jede Operation ein Zahlenpaar, also zwischen n und 2n-2 Zahlen im Log.

Bei einem Zirkeltausch oder noch komplizierteren Reihenfolgen muss ich den Sortier-Vorgang selbst analysieren für das Log (z.B. 1 -> 3, 3 -> 7, 7 -> 1 wird zu 1<->3, 1<->7) Machbar aber aufwändig...

Ich glaube, ich bleibe bei meiner Indexliste, da brauche ich fix n Zahlen und die Erstellung ist recht einfach.

Wirklich schön wäre etwas mit Speicherbedarf < n

Ich habe keinen Kontext mit Randbedingungen, die ich einbeziehen könnte. Ich habe Tabellen (oder besser Listen von gleichartigen OO-Objekten) in beliebiger unsortierter Reihenfolge, die nach frei definierbarer Ordnungsrelation (durch den Anwender definiert) sortiert werden sollen (beliebige Felder als Schlüssel, auch mehrere Felder, auf- oder absteigend) - und diese Sortier-Operation soll mit einer Undo-Funktion bei Bedarf rückgängig gemacht werden. Das ganze findet auf Tabellen im Hauptspeicher einer Anwendung statt, die ich programmieren will.

Bearbeitet 9. November 2018 von Airlag

[Kar'gos]

Musst du triviale Operationen mitprotokollieren?

1 Aprikose
2 Dattel
3 Kirsche
4 Orange
5 Pfirsich
6 Zwetschge
7 Banane

Die Anzahl der Einzeloperationen wäre zwar 7->2, 2->3, 3->4, 4->5, 5->6, 6->7, es würde aber reichen 7->2 abzuspeichern, die restlichen 5 sind zwingende Folge, könnte man also weglassen.

 

 

 

Bearbeitet 9. November 2018 von Kar'gos

[Owen]

@Airlag 

Welche Anwendung ist das? Welche Programmiersprache? Liegt dem Ganzen eine DB zu Grunde?
Du schreibst "Tabellen im Hauptspeicher", wie performant soll das sein? Von welcher Datenmenge sprechen wir hier überhaupt?

Evtl. ist simples logging die Lösung? Ich musste mal, vor Jahren, eine VB6-Anwendung schreiben die auch bei nicht vorhandener Netzanbindung (Außendienstmitarbeiter) genau so funktionieren sollte wie mit Netz. Ich konnte meinem Chef das damals nicht ausreden, also habe ich alle Commands die offline in Richtung DB gegangen sind in eine log-Datei geschrieben. Sobald der Mitarbeiter wieder im Netz war, wurden diese Commands ausgeführt. D.h. ich hab nicht die Daten an sich gespeichert, sondern nur die Aktionen. Ein rollback war dann immer noch möglich. War natürlich nicht ganz so simpel, aber mehr ins Detail möchte ich jetzt nicht gehen.

Könnte das evtl. ein Weg für dich sein?

Gruß
Owen

Bearbeitet 9. November 2018 von Owen

[Lukarnam]

vor 2 Stunden schrieb Airlag:

@Curilias thx, Der Gedanke, zusammen mit dem Beispiel sieht sehr sparsam aus.

...

Ich habe mal ein paar Szenarien durchgespielt. Abgesehen von einem Ausnahmefall wie dem Beispiel ist der günstige Fall für deinen Vorschlag eine Umkehrung der Sortier-Richtung A->Z zu Z->A, Dann kommt man mit n/2 Operationen aus (n = Länge der zu sortierenden Liste)
Schon bei folgender Konstellation, die wohl häufiger vor kommen wird, sieht es katastrophal schlechter aus
1 Aprikose
2 Dattel
3 Kirsche
4 Orange
5 Pfirsich
6 Zwetschge
7 Banane
Normal wird also irgendwas zwischen n/2 und n-1 Operationen sein, für jede Operation ein Zahlenpaar, also zwischen n und 2n-2 Zahlen im Log.

Bei einem Zirkeltausch oder noch komplizierteren Reihenfolgen muss ich den Sortier-Vorgang selbst analysieren für das Log (z.B. 1 -> 3, 3 -> 7, 7 -> 1 wird zu 1<->3, 1<->7) Machbar aber aufwändig...

Ich glaube, ich bleibe bei meiner Indexliste, da brauche ich fix n Zahlen und die Erstellung ist recht einfach.

Wirklich schön wäre etwas mit Speicherbedarf < n

Ich habe keinen Kontext mit Randbedingungen, die ich einbeziehen könnte. Ich habe Tabellen (oder besser Listen von gleichartigen OO-Objekten) in beliebiger unsortierter Reihenfolge, die nach frei definierbarer Ordnungsrelation (durch den Anwender definiert) sortiert werden sollen (beliebige Felder als Schlüssel, auch mehrere Felder, auf- oder absteigend) - und diese Sortier-Operation soll mit einer Undo-Funktion bei Bedarf rückgängig gemacht werden. Das ganze findet auf Tabellen im Hauptspeicher einer Anwendung statt, die ich programmieren will.

 

Was ist die Anforderung, wenn die Liste durch einen anderen Prozess (Anwender / Skript / ...) nach dem Sortieren, jedoch vor dem Undo verändert wird?

* wenn #3 in dem beschriebenene Zeitraum gelöscht wird?

* wenn in dem beschriebenen Zeitraum ein neuer Eintrag zwischen #2 und #3 eingefügt wird, der somit zu #3 wird?

 

 

[Airlag]

Das ist die Vorplanung für eine Open Source Tabellenkalkulation, die konzeptionell im 21. Jahrhundert steht statt in der Mitte des 20. Jahrhunderts. Ich sammle gerade hauptsächlich Ideen für die Teile, die ich auf jeden Fall dabei haben werde.

Geplante Programmiersprache: C#
Das GUI wird vollständig vektoriell sein, keine Buttons mit 16x16 Pixel Grafiken vergrößert und geblurt auf einem 4K-Display  
Datenformat wird auf jeden Fall OpenDocument
Datei-Import von .xmlx soll rein
Es wird eine Skript-Sprache integriert sein, vermutlich so etwas wie CSharpScript

Im ersten Release werden vermutlich viele Sachen nicht drin sein, die man von Excel kennt. Die Implementierung aller Funktionen, die in Formeln verwendet werden können, ist eine Fleißarbeit. Pivot-Tabellen interessieren mich nicht sonderlich.

Für mich ist das ein Proof-of-Concept Projekt - und ein Test, ob ich so was noch auf dem Kasten habe. Je nach der Resonanz, die ich bekomme, werde ich dann weiter machen oder es bleiben lassen.
Ich gehe davon aus, dass ich 2-3 Jahre bis zum ersten Release brauchen werde.