Jump to content

Computernerds unter sich - Der Computerschwampf


Recommended Posts

Am 17.2.2018 um 20:43 schrieb dabba:

Ja, der C64 war für viele spätere IT-ler der erste Kontakt mit der Computerei. Ein bezahlbares Gerät mit einer festgelegten Hardware, die ausgereizt werden wollte. Während die PC-Nutzer schon damals oft einfach neue Hardware gekauft haben, falls die alte zu langsam war. ;) 

Apple hingegen war damals schon teuer aber halt noch nicht cool und lifestylish. Apple hatte damals schon eine Fangemeinde, die war aber tendeziell längst nicht so freakig wie die C64-Szene. Auch wenn der Apple II als Heimcomputer in den Staaten durchaus populär war.

Das Tollste war, im Apple II und im C=64 steckten kompatible Prozessoren und weite Teile des Betriebssystems waren identisch. Aus Sicht eines Nerds hat man bei Äppel also dasselbe teurer bekommen.

Link to comment
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.

Edited by Airlag
  • Like 1
Link to comment
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.

Link to comment
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.

 

Link to comment
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 :)

Edited by Airlag
Link to comment
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...

Link to comment
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.

Link to comment
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).

Edited by Guest
Link to comment
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. :agadur:

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.

Link to comment
  • 3 months later...
  • 4 months later...

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?

Link to comment
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.

Edited by Lukarnam
Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment

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?

Link to comment

@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.

Edited by Airlag
Link to comment

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.

 

 

 

Edited by Kar'gos
Link to comment

@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

Edited by Owen
Link to comment
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?

 

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...