Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Jack Tramiel gestorben
7 views
Skip to first unread message
Stefan Werner
Apr 10, 2012, 10:11:19 AM4/10/12
to
Der Mann, der den einzigen Computer herstellte, den ich wirklich
vollständig verstand: Den C64.
R.I.P
-stef
vollständig verstand: Den C64.
R.I.P
-stef
Felix Rauch
Apr 11, 2012, 11:03:36 PM4/11/12
to
Stefan Werner <009w...@sneakemail.com> wrote:
> Der Mann, der den einzigen Computer herstellte, den ich wirklich
> vollst?ndig verstand: Den C64.
> Der Mann, der den einzigen Computer herstellte, den ich wirklich
> R.I.P
Und auch den ATARI ST.
In der Tat, R.I.P.
- Felix
--
Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
purposes is hereby strictly prohibited according to applicable laws.
Stefan Werner
Apr 12, 2012, 3:54:00 AM4/12/12
to
Am 12.04.12 05:03, schrieb Felix Rauch:
stimmt: Verglichen mit den damaligen IBM PC wirkte der ST äusserst
modern. Und ausserdem: Mit dem Ataris ST und Aladdin sowie einer
gecrackten Mac-Systemdisk hatte man einen bezahlbaren Mac :-)
Das Faszinierende am C64 war, dass er so einfach war. Der 6502/6510
Prozessor war im Prinzip einfach ein PLA, nichts mit Microcode und so
sondern alles fest verdrahtet. Jede Bitkombination am Eingang gab einen
Taktzyklus später eine entsprechende Reaktion. Manche
Eingangskombinationen waren dokumentiert, das waren die "offiziellen"
Maschinenbefehle, und manche waren undokumentiert, die erlaubten zum
Teil coole Abkürzungen. Und eine Stufe höher, das "Betriebssystem", war
ebenfalls leicht überschaubar. 8KB und es gab dokumentierte
ROM-Listings. Man konnte das System wirklich /verstehen/. Und mit einer
simplen Port-Anweisung konnte man des Betriebssystem ganz ausblenden und
hatte den ganzen gigantischen 64KB Adressraum für sich :-)
Ich denke, der C64 mit ein Grund dafür, dass die Nerds meiner Generation
sich mehr dafür interessierten, wie ein Programm unter der Haube
funktioniert, während die Nerds der "digital natives" sich vor allem
dafür interessieren, wie man die Eigenschaften eines Programms ausreizt
(und nicht, warum es diese Eigenschaften hat).
Ich bin noch nicht sicher, ob ich es gut oder schlecht finde, dass ich
die Hardware und das Betriebssystem der PC's meiner Kinder viel besser
behrrsche als sie, während ich keinerlei Chance habe mitzukommen, wenn
sie ein aktuelles Spiel oder "Facebook" bedienen. Ich sehe nur schnell
wechselnde Bildschirminhalte, kann diese aber selber nicht vernünftig
interpretieren oder beeinflussen.
Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
es aber nicht....
Soweit der philospohische Exkurs zm Abschied von Jack Tramiel, der das
Volk zum Computer und den Computer zum Volk brachte. (Denn eigentlich
müsste man die Story ja beim Commodore PET beginnen, dem ersten
"personal electronic transactor", später auch PC genannt.)
-stef
> Stefan Werner<009w...@sneakemail.com> wrote:
>> Der Mann, der den einzigen Computer herstellte, den ich wirklich
>> vollst?ndig verstand: Den C64.
>
>> R.I.P
>
> Und auch den ATARI ST.
Wobei TOS/AES/GEM doch immer etwas zusammengeschustert wirkte. Aber ja,
>> Der Mann, der den einzigen Computer herstellte, den ich wirklich
>> vollst?ndig verstand: Den C64.
>
>> R.I.P
>
> Und auch den ATARI ST.
stimmt: Verglichen mit den damaligen IBM PC wirkte der ST äusserst
modern. Und ausserdem: Mit dem Ataris ST und Aladdin sowie einer
gecrackten Mac-Systemdisk hatte man einen bezahlbaren Mac :-)
Das Faszinierende am C64 war, dass er so einfach war. Der 6502/6510
Prozessor war im Prinzip einfach ein PLA, nichts mit Microcode und so
sondern alles fest verdrahtet. Jede Bitkombination am Eingang gab einen
Taktzyklus später eine entsprechende Reaktion. Manche
Eingangskombinationen waren dokumentiert, das waren die "offiziellen"
Maschinenbefehle, und manche waren undokumentiert, die erlaubten zum
Teil coole Abkürzungen. Und eine Stufe höher, das "Betriebssystem", war
ebenfalls leicht überschaubar. 8KB und es gab dokumentierte
ROM-Listings. Man konnte das System wirklich /verstehen/. Und mit einer
simplen Port-Anweisung konnte man des Betriebssystem ganz ausblenden und
hatte den ganzen gigantischen 64KB Adressraum für sich :-)
Ich denke, der C64 mit ein Grund dafür, dass die Nerds meiner Generation
sich mehr dafür interessierten, wie ein Programm unter der Haube
funktioniert, während die Nerds der "digital natives" sich vor allem
dafür interessieren, wie man die Eigenschaften eines Programms ausreizt
(und nicht, warum es diese Eigenschaften hat).
Ich bin noch nicht sicher, ob ich es gut oder schlecht finde, dass ich
die Hardware und das Betriebssystem der PC's meiner Kinder viel besser
behrrsche als sie, während ich keinerlei Chance habe mitzukommen, wenn
sie ein aktuelles Spiel oder "Facebook" bedienen. Ich sehe nur schnell
wechselnde Bildschirminhalte, kann diese aber selber nicht vernünftig
interpretieren oder beeinflussen.
Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
es aber nicht....
Soweit der philospohische Exkurs zm Abschied von Jack Tramiel, der das
Volk zum Computer und den Computer zum Volk brachte. (Denn eigentlich
müsste man die Story ja beim Commodore PET beginnen, dem ersten
"personal electronic transactor", später auch PC genannt.)
-stef
Patrick Kormann
Apr 12, 2012, 9:25:54 AM4/12/12
to
Am 12.04.12 09:54, schrieb Stefan Werner:
> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
> es aber nicht....
Naja, früher hatten halt Leute Computer um des Computers willen. Heute
ist er nur noch ein Werkzeug. Und genau so wenig wie jeder
Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder
Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi
verstehen.
Das gab's übrigens durchaus auch schon vor 20, 30 Jahren, nur war es
seltener.
Ich find's auch schade, andererseits wäre es aber auch seltsam, wenn
plötzlich jeder Mensch ein 'Computerfreak' sein wollte - und benutzten
tut die Dinger heute ja fast jeder.
Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke
53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0
oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht
mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in
Assembler programmiert habe.
> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
> es aber nicht....
ist er nur noch ein Werkzeug. Und genau so wenig wie jeder
Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder
Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi
verstehen.
Das gab's übrigens durchaus auch schon vor 20, 30 Jahren, nur war es
seltener.
Ich find's auch schade, andererseits wäre es aber auch seltsam, wenn
plötzlich jeder Mensch ein 'Computerfreak' sein wollte - und benutzten
tut die Dinger heute ja fast jeder.
Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke
53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0
oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht
mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in
Assembler programmiert habe.
Stefan Werner
Apr 13, 2012, 12:37:31 PM4/13/12
to
Am 12.04.12 15:25, schrieb Patrick Kormann:
meinem ersten Auto konnte ich den Vergaser noch selber zerlegen,
durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim
heutigen Auto wüsste ich nicht mal, wo die Einspritzpumpe genau ist,
geschweige denn, dass ich irgendwas daran reparieren könnte.
Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht
starten will.
Trotzdem: Man wird immer abhängiger von Spezialisten und man wird selber
immer mehr zum Spezialisten.
> Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke
> 53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0
> oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht
> mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in
> Assembler programmiert habe.
Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
Velofahren :-)
-stef
> Am 12.04.12 09:54, schrieb Stefan Werner:
>
>> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
>> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
>> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
>> es aber nicht....
>
> Naja, früher hatten halt Leute Computer um des Computers willen. Heute
> ist er nur noch ein Werkzeug. Und genau so wenig wie jeder
> Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder
> Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi
> verstehen.
Ja, da hast Du schon Recht. Wobei beim Auto find ich's auch schade. Bei
>
>> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
>> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
>> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
>> es aber nicht....
>
> Naja, früher hatten halt Leute Computer um des Computers willen. Heute
> ist er nur noch ein Werkzeug. Und genau so wenig wie jeder
> Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder
> Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi
> verstehen.
meinem ersten Auto konnte ich den Vergaser noch selber zerlegen,
durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim
heutigen Auto wüsste ich nicht mal, wo die Einspritzpumpe genau ist,
geschweige denn, dass ich irgendwas daran reparieren könnte.
Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht
starten will.
Trotzdem: Man wird immer abhängiger von Spezialisten und man wird selber
immer mehr zum Spezialisten.
> Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke
> 53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0
> oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht
> mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in
> Assembler programmiert habe.
aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
Velofahren :-)
-stef
Patrick Kormann
Apr 15, 2012, 5:35:01 PM4/15/12
to
Am 13.04.12 18:37, schrieb Stefan Werner:
> Ja, da hast Du schon Recht. Wobei beim Auto find ich's auch schade. Bei
> meinem ersten Auto konnte ich den Vergaser noch selber zerlegen,
> durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim
> heutigen Auto wüsste ich nicht mal, wo die Einspritzpumpe genau ist,
> geschweige denn, dass ich irgendwas daran reparieren könnte.
> Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht
> starten will.
> Trotzdem: Man wird immer abhängiger von Spezialisten und man wird selber
> immer mehr zum Spezialisten.
Schade find ich's auch! Ich würd mein Auto gern selbst reparieren können
:) ... Mein Vater und mein Bruder sind ja gute Mechaniker, allerdings
zumindest der Papa halt eher bei der rustikaleren Technik. Bruder hat
glaub ich auch schon mit Fahrzeugelektronik etwas erfahrung, aber
naja... Ohne richtige Werkstatt kommst du wohl selbst mit dem Knowhow
nicht weiter.
Was den Rest angeht, werd ich langsam schon noch zum Heimwerker, ich
kämpf hier mit Elektrik, Ölheizung und Elektroboiler gleichzeitig ;)
> Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
> Velofahren :-)
Ne, das wusste ich nicht mehr. Aus dem Basic hab ich halt eher den sys
gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die
man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch
nicht gearbeitet? Weiss es nicht mehr ;)
> Ja, da hast Du schon Recht. Wobei beim Auto find ich's auch schade. Bei
> meinem ersten Auto konnte ich den Vergaser noch selber zerlegen,
> durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim
> heutigen Auto wüsste ich nicht mal, wo die Einspritzpumpe genau ist,
> geschweige denn, dass ich irgendwas daran reparieren könnte.
> Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht
> starten will.
> Trotzdem: Man wird immer abhängiger von Spezialisten und man wird selber
> immer mehr zum Spezialisten.
:) ... Mein Vater und mein Bruder sind ja gute Mechaniker, allerdings
zumindest der Papa halt eher bei der rustikaleren Technik. Bruder hat
glaub ich auch schon mit Fahrzeugelektronik etwas erfahrung, aber
naja... Ohne richtige Werkstatt kommst du wohl selbst mit dem Knowhow
nicht weiter.
Was den Rest angeht, werd ich langsam schon noch zum Heimwerker, ich
kämpf hier mit Elektrik, Ölheizung und Elektroboiler gleichzeitig ;)
> Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
> Velofahren :-)
gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die
man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch
nicht gearbeitet? Weiss es nicht mehr ;)
Mario Rothacher
Apr 16, 2012, 3:46:41 AM4/16/12
to
Patrick Kormann wrote:
> Am 13.04.12 18:37, schrieb Stefan Werner:
> Am 13.04.12 18:37, schrieb Stefan Werner:
>> Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
>> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
>> Velofahren :-)
>
> Ne, das wusste ich nicht mehr. Aus dem Basic hab ich halt eher den sys
> gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die
> man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch
> nicht gearbeitet? Weiss es nicht mehr ;)
Naja, mit Hex scheinst Du wohl auf Kriegsfuss zu stehen, sonst wüsstest
>> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
>> Velofahren :-)
>
> Ne, das wusste ich nicht mehr. Aus dem Basic hab ich halt eher den sys
> gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die
> man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch
> nicht gearbeitet? Weiss es nicht mehr ;)
Du, so wie Stefan es erwähnt, dass $C000 eben #49152 entspricht. Und sys
war eben das Commodore-Basic-Äquivalent für den 6510-Befehl jmp.
Der C64 war schon ein geniales Kistchen bei welche ich auch beinahe
alles verstand. Assembler hab ich mit dem Ding auch gemacht. Aber noch
so richtig alles zu Fuss :)
Also Assemblercode auf Papier geschrieben.
Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
geschrieben:
10 FOR X=1TO105
20 READ A
30 POKE 1000+X,A
40 NEXT A
50 SYS 1001
60 DATA 123,232,123,221,...
Ja, das waren noch Zeiten. Aber der VC20 und die Nachfolger waren dafür
verantwortlich, was ich heute bin :)
cu
Mario
Patrick Kormann
Apr 16, 2012, 6:47:54 AM4/16/12
to
Am 16.04.12 09:46, schrieb Mario Rothacher:
> Naja, mit Hex scheinst Du wohl auf Kriegsfuss zu stehen, sonst wüsstest
> Du, so wie Stefan es erwähnt, dass $C000 eben #49152 entspricht. Und sys
> war eben das Commodore-Basic-Äquivalent für den 6510-Befehl jmp.
Was du nicht sagst. Aber wenn ich ein Programm lade, bin ich im Basic.
Dann starte ich das mit sys 49152, wenn es dort im Speicher steht. Im
Programm selbst springe ich relativ selten an die aller erste Adresse
des Programms, sondern an eine höhere. Darum mein Beispiel mit $C020
(was auch andeuten sollte, dass die Programme nicht allzu lang waren)
> Also Assemblercode auf Papier geschrieben.
> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
> geschrieben:
Uff, also so wie die Listings in den Heftchen standen fast. Etwas aufwändig.
> 10 FOR X=1TO105
> 20 READ A
> 30 POKE 1000+X,A
> 40 NEXT A
> 50 SYS 1001
> 60 DATA 123,232,123,221,...
Siehe Zeile 50.. oder stehst du auch mit Hex auf Kriegsfuss ;)
> Naja, mit Hex scheinst Du wohl auf Kriegsfuss zu stehen, sonst wüsstest
> Du, so wie Stefan es erwähnt, dass $C000 eben #49152 entspricht. Und sys
> war eben das Commodore-Basic-Äquivalent für den 6510-Befehl jmp.
Dann starte ich das mit sys 49152, wenn es dort im Speicher steht. Im
Programm selbst springe ich relativ selten an die aller erste Adresse
des Programms, sondern an eine höhere. Darum mein Beispiel mit $C020
(was auch andeuten sollte, dass die Programme nicht allzu lang waren)
> Also Assemblercode auf Papier geschrieben.
> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
> geschrieben:
> 10 FOR X=1TO105
> 20 READ A
> 30 POKE 1000+X,A
> 40 NEXT A
> 50 SYS 1001
> 60 DATA 123,232,123,221,...
Mario Rothacher
Apr 17, 2012, 2:48:04 AM4/17/12
to
Patrick Kormann wrote:
> Am 16.04.12 09:46, schrieb Mario Rothacher:
> Am 16.04.12 09:46, schrieb Mario Rothacher:
>> Also Assemblercode auf Papier geschrieben.
>> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
>> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
>> geschrieben:
>
> Uff, also so wie die Listings in den Heftchen standen fast. Etwas
> aufwändig.
>
>> 10 FOR X=1TO105
>> 20 READ A
>> 30 POKE 1000+X,A
>> 40 NEXT A
>> 50 SYS 1001
>> 60 DATA 123,232,123,221,...
>
> Siehe Zeile 50.. oder stehst du auch mit Hex auf Kriegsfuss ;)
Nein, aber Commodore Basic :) Sonst hätte man noch einen
>> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
>> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
>> geschrieben:
>
> Uff, also so wie die Listings in den Heftchen standen fast. Etwas
> aufwändig.
>
>> 10 FOR X=1TO105
>> 20 READ A
>> 30 POKE 1000+X,A
>> 40 NEXT A
>> 50 SYS 1001
>> 60 DATA 123,232,123,221,...
>
> Siehe Zeile 50.. oder stehst du auch mit Hex auf Kriegsfuss ;)
Hex-Dez-Umrechner im Basic-Loader einbauen müssen.
Aber mein Beispiel ist trotzdem nicht so schön, ab 1024 schrieb man
direkt auf den Bildschirm. Man konnte zwar auch dort Programmcode
hinschreiben, aber der wurde dann relativ rasch überschrieben...
Wie hast Du den Assembler programmiert? Hattest Du dazu tatsächlich
einen Assemblierer?
cu
Mario
Stefan Werner
Apr 17, 2012, 3:20:40 AM4/17/12
to
Am 17.04.12 08:48, schrieb Mario Rothacher:
er der wurde dann relativ rasch überschrieben...
>
> Wie hast Du den Assembler programmiert? Hattest Du dazu tatsächlich
> einen Assemblierer?
Also ich hatte den "Data Becker ProfiMat".
Mein erstes grosses Projekt war, den Assembler selber selber zu
dissasemblieren und zu patchen, um den Kopierschutz zu knacken. Dieser
war nämlich besonders fies: Wenn man ihn von einer Sicherungskopie
startete, stürzte er nach ca. einer halben Stunde mit der Meldung
"Sorry, Hacker" ab und man hatte alles noch Ungesicherte verloren....
Glücklicherweise war der Kopierschutz naiv implementiert. Er testete auf
einen bestimmten kaputten Sektor auf der Originaldiskette. Man konnte
aber den "jsr <testroutine>" einfach mit "nop" überschreiben, das war's
dann :-)
Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
Projekte damit erstellen. Und auch der dazugehörige Disassembler und
Debugger waren richtig gut.
Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
mit GFA-Basic.
-stef
er der wurde dann relativ rasch überschrieben...
>
> Wie hast Du den Assembler programmiert? Hattest Du dazu tatsächlich
> einen Assemblierer?
Mein erstes grosses Projekt war, den Assembler selber selber zu
dissasemblieren und zu patchen, um den Kopierschutz zu knacken. Dieser
war nämlich besonders fies: Wenn man ihn von einer Sicherungskopie
startete, stürzte er nach ca. einer halben Stunde mit der Meldung
"Sorry, Hacker" ab und man hatte alles noch Ungesicherte verloren....
Glücklicherweise war der Kopierschutz naiv implementiert. Er testete auf
einen bestimmten kaputten Sektor auf der Originaldiskette. Man konnte
aber den "jsr <testroutine>" einfach mit "nop" überschreiben, das war's
dann :-)
Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
Projekte damit erstellen. Und auch der dazugehörige Disassembler und
Debugger waren richtig gut.
Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
mit GFA-Basic.
-stef
Mario Rothacher
Apr 17, 2012, 3:59:30 AM4/17/12
to
Stefan Werner wrote:
> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
> Projekte damit erstellen. Und auch der dazugehörige Disassembler und
> Debugger waren richtig gut.
> Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
> mit GFA-Basic.
Mit Basic hab ich überhaupt angefangen mich mit Computern zu intressieren...
> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
> Projekte damit erstellen. Und auch der dazugehörige Disassembler und
> Debugger waren richtig gut.
> Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
> mit GFA-Basic.
Auf dem VC20 hab ich in Basic im zur Verfügung stehenden RAM von Sage
und schreibe 3.5kByte Pac-Man programmiert. Leider hatte es einen Fehler
und man konnte den Pac-Man aus dem Bildschirmspeicher laufen lassen :).
Der lief dann durch den Speicher und veränderte natürlich den Basic-Code
oder in entgegengesetzter Richtung Systembereiche. Hatte ganz schöne
Effekte.
Heute ist ja schon das dümmste Programm mindestens 1MByte gross...
Damals musste man noch Bit zählen :)
Stefan Werner
Apr 17, 2012, 8:00:34 AM4/17/12
to
Am 17.04.12 09:59, schrieb Mario Rothacher:
Programmen, die durch den Speicher marodieren hat später ja Alex Dewdney
mit seinen "core wars" aufgegriffen. Es gab da glaube ich sogar richtige
Meisterschaften.
Heute ist ja schon das dümmste Programm mindestens 1MByte gross...
> Damals musste man noch Bit zählen :)
Ja, das hinterliess bei mir gewisse Schäden. Ich hab auch dann noch viel
zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das
längst nicht mehr nötig war...
-stef
> Stefan Werner wrote:
>> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
>> Projekte damit erstellen. Und auch der dazugehörige Disassembler und
>> Debugger waren richtig gut.
>> Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
>> mit GFA-Basic.
>
> Mit Basic hab ich überhaupt angefangen mich mit Computern zu
> intressieren...
> Auf dem VC20 hab ich in Basic im zur Verfügung stehenden RAM von Sage
> und schreibe 3.5kByte Pac-Man programmiert. Leider hatte es einen Fehler
> und man konnte den Pac-Man aus dem Bildschirmspeicher laufen lassen :).
> Der lief dann durch den Speicher und veränderte natürlich den Basic-Code
> oder in entgegengesetzter Richtung Systembereiche. Hatte ganz schöne
> Effekte.
Du hättest Dir das patentieren lassen sollen ;-). Das Konzept von
>> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
>> Projekte damit erstellen. Und auch der dazugehörige Disassembler und
>> Debugger waren richtig gut.
>> Mit Basic konnte ich mich erst viel später anfreunden, auf dem Atari ST
>> mit GFA-Basic.
>
> Mit Basic hab ich überhaupt angefangen mich mit Computern zu
> intressieren...
> Auf dem VC20 hab ich in Basic im zur Verfügung stehenden RAM von Sage
> und schreibe 3.5kByte Pac-Man programmiert. Leider hatte es einen Fehler
> und man konnte den Pac-Man aus dem Bildschirmspeicher laufen lassen :).
> Der lief dann durch den Speicher und veränderte natürlich den Basic-Code
> oder in entgegengesetzter Richtung Systembereiche. Hatte ganz schöne
> Effekte.
Programmen, die durch den Speicher marodieren hat später ja Alex Dewdney
mit seinen "core wars" aufgegriffen. Es gab da glaube ich sogar richtige
Meisterschaften.
Heute ist ja schon das dümmste Programm mindestens 1MByte gross...
> Damals musste man noch Bit zählen :)
zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das
längst nicht mehr nötig war...
-stef
Mario Rothacher
Apr 17, 2012, 11:08:28 AM4/17/12
to
Stefan Werner wrote:
> Am 17.04.12 09:59, schrieb Mario Rothacher:
> Am 17.04.12 09:59, schrieb Mario Rothacher:
> Heute ist ja schon das dümmste Programm mindestens 1MByte gross...
>> Damals musste man noch Bit zählen :)
> Ja, das hinterliess bei mir gewisse Schäden. Ich hab auch dann noch viel
> zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das
> längst nicht mehr nötig war...
Taktzyklen zählen war dann erst wieder in der Elektronikerlehre ein
>> Damals musste man noch Bit zählen :)
> Ja, das hinterliess bei mir gewisse Schäden. Ich hab auch dann noch viel
> zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das
> längst nicht mehr nötig war...
Thema. Als wir mit einem Mikroprozessorkit (Genauer Typ weiss ich nicht
mehr, aber Motorola, ähnlich einfach wie 6510) und einem Roboterbausatz
ein Assemblerprogramm erstellt haben, welches den Turm zu Hanoi physisch
löste. Da der Roboterbausatz ziemlich doof war (Widerstandsmessung zur
Positionsbestimmung mit reichlich Spiel), hat man die ungefähre Position
mit Vollspeed überfahren, dann getaktet (somit kontroliert langsamer)
zurückgefahren bis die Zielposition erreicht wurde. So konnte man das
Spiel einwenig aufheben und der Roboter hat Tagaus Tagein Stapel von
einer Säule zur anderen verschoben. Irgendwann war die so erreichte
Genauigkeit jedoch trotzdem noch zu ungenau und der Turm stürzte ein.
Seit diesem Programm weiss ich rekursives Programmieren zu schätzen :)
Patrick Kormann
Apr 17, 2012, 2:04:50 PM4/17/12
to
Am 17.04.12 08:48, schrieb Mario Rothacher:
> Aber mein Beispiel ist trotzdem nicht so schön, ab 1024 schrieb man
> direkt auf den Bildschirm. Man konnte zwar auch dort Programmcode
> hinschreiben, aber der wurde dann relativ rasch überschrieben...
Ach, das wusste ich auch nicht mehr. Das gab's ja noch oft, dass
> direkt auf den Bildschirm. Man konnte zwar auch dort Programmcode
> hinschreiben, aber der wurde dann relativ rasch überschrieben...
Programme 'sich' erst auf den Schirm geschrieben haben und dann von dort
ausgeführt.. Hatte ich völlig vergessen.
> Wie hast Du den Assembler programmiert? Hattest Du dazu tatsächlich
> einen Assemblierer?
gesagt hatte ich auf dem C64 auch praktisch nur Raubkopien. Meine Mama
hat mir mal das Game Elite zu Weihnachten geschenkt. Ich war bass
erstaunt ab der Geldverschwendung :) ... Aber ich habe das Game dann
doch mehr geschätzt als jedes andere und irgendwie hat's doch Eindruck
hinterlassen.
Aber ich bin so ehrlich: Ohne schier endlose Zufuhr an Raubkopien hätte
ich mich wohl gar nie für den Compi interessiert. Ich kann mich noch
erinnern, dass ich auf nem Sharm MZ 80a oder so Basic programmiert habe
(so ne langweilige Büromaschine mit Grünstufen-Display) und den C64 gar
nie beachtet habe, weil das Basic so grottenschlecht war. Bis da jemand
mal das Game 'Benji' geladen hat. Nicht die Graphik hat mich umgehauen
(obwohl die auch ganz passabel war), sondern der Sound. Von da an wusste
ich, was ich haben musste.
Irgendwann hatte ich übrigens ein SFD 1001. Brauchte ein modifiziertes
ROM, welches ich in Form eines EPROM-Umschalters im Gerät hatte. Wow das
war heiss, 1 MB pro Diskette sichern, da ging der Platz nie mehr aus.
Und relativ schnell war es auch noch, auch wenn gewisse Fastloader aus
dem 1541 ja auch schon einiges raus holten ;)
Felix Rauch
Apr 20, 2012, 7:23:10 AM4/20/12
to
Stefan Werner <009w...@sneakemail.com> wrote:
> Am 12.04.12 05:03, schrieb Felix Rauch:
> > Stefan Werner<009w...@sneakemail.com> wrote:
> >> Der Mann, der den einzigen Computer herstellte, den ich wirklich
> >> vollst?ndig verstand: Den C64.
> >
> >> R.I.P
> >
> > Und auch den ATARI ST.
> Wobei TOS/AES/GEM doch immer etwas zusammengeschustert wirkte.
Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> Am 12.04.12 05:03, schrieb Felix Rauch:
> > Stefan Werner<009w...@sneakemail.com> wrote:
> >> Der Mann, der den einzigen Computer herstellte, den ich wirklich
> >> vollst?ndig verstand: Den C64.
> >
> >> R.I.P
> >
> > Und auch den ATARI ST.
> Wobei TOS/AES/GEM doch immer etwas zusammengeschustert wirkte.
lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
hatte man selber direkt zur Verfuegung :-)
Felix Rauch
Apr 20, 2012, 7:24:26 AM4/20/12
to
Stefan Werner <009w...@sneakemail.com> wrote:
[...]
> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
> immer mehr zum Spezialisten.
Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
muss auch noch die richtige Software haben um das Auto zu debuggen :-/
[...]
> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
> immer mehr zum Spezialisten.
Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
muss auch noch die richtige Software haben um das Auto zu debuggen :-/
Felix Rauch
Apr 20, 2012, 7:28:18 AM4/20/12
to
> Mit Basic konnte ich mich erst viel sp?ter anfreunden, auf dem Atari ST
> mit GFA-Basic.
Ach, Gfa-Basic, das war noch was. Zuerst angefangen hatte ich mit dem
Atari ST Basic, aber Gfa-Basic war natuerlich um einiges besser. Leider
immer noch nicht ausreichend fuer meine Zwecke, deshalb hatte ich dann
Assembler gelernt. 68000er-Assembler war ja eigentlich recht komfortabel.
> mit GFA-Basic.
Ach, Gfa-Basic, das war noch was. Zuerst angefangen hatte ich mit dem
Atari ST Basic, aber Gfa-Basic war natuerlich um einiges besser. Leider
immer noch nicht ausreichend fuer meine Zwecke, deshalb hatte ich dann
Assembler gelernt. 68000er-Assembler war ja eigentlich recht komfortabel.
Patrick Kormann
Apr 20, 2012, 8:18:04 AM4/20/12
to
Am 20.04.12 13:23, schrieb Felix Rauch:
> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> hatte man selber direkt zur Verfuegung :-)
Ja aber der Atari... bäh.. :)
Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
besser um die Eigenheiten der Hardware als der Programmierer. Und
spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
kompliziert werden.
> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> hatte man selber direkt zur Verfuegung :-)
Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
besser um die Eigenheiten der Hardware als der Programmierer. Und
spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
kompliziert werden.
Mario Rothacher
Apr 20, 2012, 9:32:21 AM4/20/12
to
wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
Endlosloop-Programmiere sieht man im Taskmanager dass bei einem
Dual-Core die Auslastung eines einzelnen Cores auf 100% ansteigt...
Das mit dem mehrere Cores gleichmässig zu befeuern passiert eben quasi
automatisch, da selten nur ein Prozess auf einer Kiste läuft. Insofern
sollte das nicht so wirklich kompliziert sein.
Aber so tief mit Hardware habe ich mich seit über 20 Jahren eigentlich
nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
MHz-Bereich getaktet wurden, spielte die Ausführungszeit natürlich noch
eine viel wichtigere Rolle als heute... Da darf man ruhig in
Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
Maschinencode übersetzt ist meiner Meinung trotzdem vorzuziehen, zum
Beispiel C,C++ oder das unterschätzte Delphi.
cu
Mario
Patrick Kormann
Apr 20, 2012, 10:21:44 AM4/20/12
to
Am 20.04.12 15:32, schrieb Mario Rothacher:
> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> Endlosloop-Programmiere sieht man im Taskmanager dass bei einem
> Dual-Core die Auslastung eines einzelnen Cores auf 100% ansteigt...
Ja richtig. Aber mach nur schon mal mehrere Threads und handle die...
Ohne OS, mein ich.
> Das mit dem mehrere Cores gleichmässig zu befeuern passiert eben quasi
> automatisch, da selten nur ein Prozess auf einer Kiste läuft. Insofern
> sollte das nicht so wirklich kompliziert sein.
Wir hatten es gerade von 'totaler Kontrolle' am OS vorbei. Da stell ich
mir das auch noch irgendwie kompliziert vor.
Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen
Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
Befehle, die voneinander unabhängig sind so um, dass möglichst wenige
Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
lange prefetch Queue) , sorgt dafür, dass Funktionseinheiten, die
parallel betrieben werden können (das ist nicht dasselbe wie
Multithreading) auch dementsprechend Daten kriegen etc. etc.
Ich stell mir das schon noch sau kompliziert vor.
> Aber so tief mit Hardware habe ich mich seit über 20 Jahren eigentlich
> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
> MHz-Bereich getaktet wurden, spielte die Ausführungszeit natürlich noch
> eine viel wichtigere Rolle als heute... Da darf man ruhig in
> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
> Maschinencode übersetzt ist meiner Meinung trotzdem vorzuziehen, zum
> Beispiel C,C++ oder das unterschätzte Delphi.
Ich weiss nicht, Java fand ich immer schon grottig. Ich les mich (mal
wieder) in Objective C ein, das ist schon noch elegant. Delphi, ja, da
war mal was... Ehrlich gesagt k.a. mehr ob ich damit wirklich was
gemacht habe oder nicht. Ich weiss nur noch, dass es eigentlich immer
als unterschätzt galt ;)
> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> Endlosloop-Programmiere sieht man im Taskmanager dass bei einem
> Dual-Core die Auslastung eines einzelnen Cores auf 100% ansteigt...
Ohne OS, mein ich.
> Das mit dem mehrere Cores gleichmässig zu befeuern passiert eben quasi
> automatisch, da selten nur ein Prozess auf einer Kiste läuft. Insofern
> sollte das nicht so wirklich kompliziert sein.
mir das auch noch irgendwie kompliziert vor.
Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen
Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
Befehle, die voneinander unabhängig sind so um, dass möglichst wenige
Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
lange prefetch Queue) , sorgt dafür, dass Funktionseinheiten, die
parallel betrieben werden können (das ist nicht dasselbe wie
Multithreading) auch dementsprechend Daten kriegen etc. etc.
Ich stell mir das schon noch sau kompliziert vor.
> Aber so tief mit Hardware habe ich mich seit über 20 Jahren eigentlich
> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
> MHz-Bereich getaktet wurden, spielte die Ausführungszeit natürlich noch
> eine viel wichtigere Rolle als heute... Da darf man ruhig in
> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
> Maschinencode übersetzt ist meiner Meinung trotzdem vorzuziehen, zum
> Beispiel C,C++ oder das unterschätzte Delphi.
wieder) in Objective C ein, das ist schon noch elegant. Delphi, ja, da
war mal was... Ehrlich gesagt k.a. mehr ob ich damit wirklich was
gemacht habe oder nicht. Ich weiss nur noch, dass es eigentlich immer
als unterschätzt galt ;)
Stefan Werner
Apr 20, 2012, 12:35:47 PM4/20/12
to
Am 20.04.12 15:32, schrieb Mario Rothacher:
> Patrick Kormann wrote:
>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>
>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>> hatte man selber direkt zur Verfuegung :-)
>>
>> Ja aber der Atari... bäh.. :)
>> Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>> spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
>> kompliziert werden.
>
> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>
>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>> hatte man selber direkt zur Verfuegung :-)
>>
>> Ja aber der Atari... bäh.. :)
>> Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>> spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
>> kompliziert werden.
>
> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
übernimmst, also das OS aussen vor lässt (d.h. eigentlich: Dein eigenes
Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
passiert. Vermutlich läuft das Programm dann nur auf einem Core und die
anderen hängen faul in der Gegend rum.
Oder liege ich da jetzt völlig falsch?
(Wie gesagt, der C64 war der einzige Computer, den ich vollständig
verstand. Heute kenne ich mich nur noch mit Java und Scala aus und den
Rest überlasse ich dem Compiler und dem OS. Was den netten Nebeneffekt
hat, dass es letztlich auch egal ist, ob auf dem Computer nun Linux,
Windows oder MacOS läuft :-))
-stef
Peter Rohrer
Apr 20, 2012, 2:16:07 PM4/20/12
to
Stefan Werner wrote:
> Am 20.04.12 15:32, schrieb Mario Rothacher:
>> Patrick Kormann wrote:
>>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>>
>>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>>> hatte man selber direkt zur Verfuegung :-)
>>>
>>> Ja aber der Atari... bäh.. :)
>>> Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
>>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>>> spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
>>> kompliziert werden.
>>
>> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
>> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
>
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> übernimmst, also das OS aussen vor lässt (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich läuft das Programm dann nur auf einem Core und die
> anderen hängen faul in der Gegend rum.
>
Vermutlich, hängt davon ab wie das BIOS die CPU konfiguriert hat (SMP
> Am 20.04.12 15:32, schrieb Mario Rothacher:
>> Patrick Kormann wrote:
>>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>>
>>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>>> hatte man selber direkt zur Verfuegung :-)
>>>
>>> Ja aber der Atari... bäh.. :)
>>> Aber ernsthaft, das könnte man ja heute genau so machen. Nur irgendwie
>>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>>> spätestens mehrere Cores gleichmässig zu befeuern dürfte manuell echt
>>> kompliziert werden.
>>
>> Normalerweise läuft ein Programm in n-threads. Jeder einzelner Thread
>> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
>
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> übernimmst, also das OS aussen vor lässt (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich läuft das Programm dann nur auf einem Core und die
> anderen hängen faul in der Gegend rum.
>
aktiviert?, SMT [Hyperthreading] aktiviert?, etc). Moderne CPUs sind
immerhin so intelligent nicht benutze Funktionseinheiten schlafen zu legen
(weiss jetzt nicht, ob das auch erst vom Bios aktiviert werden muss).
> Oder liege ich da jetzt völlig falsch?
> (Wie gesagt, der C64 war der einzige Computer, den ich vollständig
> verstand.
>
Gruss,
Peter
Peter Rohrer
Apr 20, 2012, 2:16:08 PM4/20/12
to
Patrick Kormann wrote:
> Am 20.04.12 15:32, schrieb Mario Rothacher:
>
> Am 20.04.12 15:32, schrieb Mario Rothacher:
>
>> Das mit dem mehrere Cores gleichmässig zu befeuern passiert eben quasi
>> automatisch, da selten nur ein Prozess auf einer Kiste läuft. Insofern
>> sollte das nicht so wirklich kompliziert sein.
>
>> automatisch, da selten nur ein Prozess auf einer Kiste läuft. Insofern
>> sollte das nicht so wirklich kompliziert sein.
>
> Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen
> Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
> Befehle, die voneinander unabhängig sind so um, dass möglichst wenige
> Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
> lange prefetch Queue) , sorgt dafür, dass Funktionseinheiten, die
>
Der P4 war auch ne Elektroheizung mit Abrechenleistung, die Verantwortlichen
> Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
> Befehle, die voneinander unabhängig sind so um, dass möglichst wenige
> Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
> lange prefetch Queue) , sorgt dafür, dass Funktionseinheiten, die
>
die DAS verbrochen haben müssten echt mal öffentlich bestraft werden :-|
> parallel betrieben werden können (das ist nicht dasselbe wie
>
> Multithreading) auch dementsprechend Daten kriegen etc. etc.
> Ich stell mir das schon noch sau kompliziert vor.
>
optimiert, merkt man gut am Atom. Der hat keine Out of Order Execution (Das
heisst die CPU kann Befehle nicht umsortieren um die Auslastung der
Pipeline zu verbessern), dementsprechend bringt Hyperthreading (welches
einen zweiten CPU-Kern simuliert, welcher die freien Funktionseinheiten
nutzt) viel mehr (relativ gesehen) als auf anderen Intel-Chips.
Allgemein kann man sagen, das heutige CPUs extrem gut sind darin das was an
Code ankommt optimal umzusortieren und bei Sprüngen richtig zu schätzen.
Ansonsten würde wesentlich weniger von der theoretischen Rechenleistung
beim Anwender ankommen.
Ich habe mal ein interessantes Paper zu dem ganzen gelesen, finde es aber
nicht mehr. Als Nicht-Proprammierer liest sich das immer sehr interessant,
aber hat wenig Einfluss auf meine Arbeit als Sysadmin.
Was heute zusehends wichtiger wird sind die ganzen SSE-Instruktionen als
Ergänzung zu x86, da muss man glaub ich aber auch Quellcode teilweise etwas
präparieren, damit der Compiler das nutzt. Abgesehen von wenigen Ausnahmen
(Irgendwie muss Intel ja demonstrieren, wozu man das braucht) werden die
Funktionen im Massenmarkt geschätzt 10 Jahre nach Markteinführung genutzt,
damit garantiert jeder potentielle Kunde auch kompatible Hardware hat.
Eine interessante Ausnahme ist die AES-Verschlüsselung, welche Intel in den
Core i eingeführt hat, und welche vom Markt sehr schnell aufgenommen wurde.
>> Aber so tief mit Hardware habe ich mich seit über 20 Jahren eigentlich
>> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
>> MHz-Bereich getaktet wurden, spielte die Ausführungszeit natürlich noch
>> eine viel wichtigere Rolle als heute... Da darf man ruhig in
>> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
>> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
>> Maschinencode übersetzt ist meiner Meinung trotzdem vorzuziehen, zum
>> Beispiel C,C++ oder das unterschätzte Delphi.
>
> Ich weiss nicht, Java fand ich immer schon grottig.
>
noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
fressen, zumindest verglichen mit C-Programmen.
Gruss,
Peter
Patrick Kormann
Apr 20, 2012, 6:26:59 PM4/20/12
to
Am 20.04.12 18:35, schrieb Stefan Werner:
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> übernimmst, also das OS aussen vor lässt (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich läuft das Programm dann nur auf einem Core und die
> anderen hängen faul in der Gegend rum.
Irgendwie muss man die Cores ja per Befehl befüllen können, sonst könnte
das OS das auch nicht. Aber ich habe keine Ahnung, wie das geht.
INTEL Assembler fand ich sowieso immer... scheusslich.
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> übernimmst, also das OS aussen vor lässt (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich läuft das Programm dann nur auf einem Core und die
> anderen hängen faul in der Gegend rum.
das OS das auch nicht. Aber ich habe keine Ahnung, wie das geht.
INTEL Assembler fand ich sowieso immer... scheusslich.
Patrick Kormann
Apr 20, 2012, 6:29:57 PM4/20/12
to
Am 20.04.12 20:16, schrieb Peter Rohrer:
> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java nicht
> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
> fressen, zumindest verglichen mit C-Programmen.
Ich spreche aber nicht unbedingt nur von der Performance, sondern davon,
dass Java meist benutzt wird um OS-Unabhängige Programme zu schreiben.
Die sehen dann auf *jedem* OS aus wie ein 20 jähriger Fremdkörper. In
wiefern man mit Java z.B. an die ganze Cocoa API überhaupt ran käme
weiss ich wiederum nicht.
Aber IMHO spielt es eh keine Rolle, ob man da nun Java oder Objective C
nimmt. Die Sprache ist ja nicht das Problem. Das API zu verstehen, das
ist die grosse Kunst. OS X kann in etwa alles schon, nur ist der
API-Aufruf teilweise so komplex wie ein mittelkompliziertes Programm ;)
Und vor allem muss man erst mal WISSEN dass es den Aufruf schon gibt und
dann muss man ihn noch finden...
> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java nicht
> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
> fressen, zumindest verglichen mit C-Programmen.
dass Java meist benutzt wird um OS-Unabhängige Programme zu schreiben.
Die sehen dann auf *jedem* OS aus wie ein 20 jähriger Fremdkörper. In
wiefern man mit Java z.B. an die ganze Cocoa API überhaupt ran käme
weiss ich wiederum nicht.
Aber IMHO spielt es eh keine Rolle, ob man da nun Java oder Objective C
nimmt. Die Sprache ist ja nicht das Problem. Das API zu verstehen, das
ist die grosse Kunst. OS X kann in etwa alles schon, nur ist der
API-Aufruf teilweise so komplex wie ein mittelkompliziertes Programm ;)
Und vor allem muss man erst mal WISSEN dass es den Aufruf schon gibt und
dann muss man ihn noch finden...
Stefan Werner
Apr 21, 2012, 1:43:20 AM4/21/12
to
Am 21.04.12 00:29, schrieb Patrick Kormann:
davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst wäre es
nicht mehr systemunabhängig)
Und @Peter zum Ressourcenhunger: Kann man so eigentlich nicht mehr
sagen. Aktuelle Java-Compiler und JVM's sind ziemlich effizient
geworden. Natürlich nie ganz so, wie für den verwendeten Prozessor
optimierter Maschinencode eines C-Compilers, klar.
Spielt aber eigentlich für die meisten Zwecke eh keine Rolle, da bei den
meisten Standardaufgaben die CPU 90% ihrer Zeit mit Warten verbringt und
Speichermangel nicht mehr wirklich ein Problem ist.
Was hingegen einschenkt ist die eingesparte Entwicklungszeit. Ein
nichttriviales Programm in C/C++ zu entwickeln, zu debuggen und auf
mehrere Plattformen zu portieren braucht locker das 5-fache an
Entwicklerstunden, wie in Java. Und da freie Entwickler zwischen 100.-
und 150.- pro Stunde kosten, kann die Differenz zwischen 50 und 250
Stunden schon ziemlich matchentscheidend sein.
Natürlich kommt es auch immer aufs Umfeld an, in dem man sich bewegt.
Bei IT-Dienstleistern liegt Java klar vorne (S. z.B. hier:
http://www.heise.de/developer/meldung/Umfrage-Java-ist-verbreitetste-Programmiersprache-bei-IT-Dienstleistern-1198249.html),
während im high performance computing Bereich C/C++ vermutlich seinen
Platz noch lange halten wird.
-stef
> Am 20.04.12 20:16, schrieb Peter Rohrer:
>
>> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java
>> nicht
>> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
>> fressen, zumindest verglichen mit C-Programmen.
>
> Ich spreche aber nicht unbedingt nur von der Performance, sondern davon,
> dass Java meist benutzt wird um OS-Unabhängige Programme zu schreiben.
> Die sehen dann auf *jedem* OS aus wie ein 20 jähriger Fremdkörper. In
> wiefern man mit Java z.B. an die ganze Cocoa API überhaupt ran käme
> weiss ich wiederum nicht.
Also da muss ich jetzt doch mal eine Lanze brechen: Das hängt doch sehr
>
>> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java
>> nicht
>> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
>> fressen, zumindest verglichen mit C-Programmen.
>
> Ich spreche aber nicht unbedingt nur von der Performance, sondern davon,
> dass Java meist benutzt wird um OS-Unabhängige Programme zu schreiben.
> Die sehen dann auf *jedem* OS aus wie ein 20 jähriger Fremdkörper. In
> wiefern man mit Java z.B. an die ganze Cocoa API überhaupt ran käme
> weiss ich wiederum nicht.
davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst wäre es
nicht mehr systemunabhängig)
Und @Peter zum Ressourcenhunger: Kann man so eigentlich nicht mehr
sagen. Aktuelle Java-Compiler und JVM's sind ziemlich effizient
geworden. Natürlich nie ganz so, wie für den verwendeten Prozessor
optimierter Maschinencode eines C-Compilers, klar.
Spielt aber eigentlich für die meisten Zwecke eh keine Rolle, da bei den
meisten Standardaufgaben die CPU 90% ihrer Zeit mit Warten verbringt und
Speichermangel nicht mehr wirklich ein Problem ist.
Was hingegen einschenkt ist die eingesparte Entwicklungszeit. Ein
nichttriviales Programm in C/C++ zu entwickeln, zu debuggen und auf
mehrere Plattformen zu portieren braucht locker das 5-fache an
Entwicklerstunden, wie in Java. Und da freie Entwickler zwischen 100.-
und 150.- pro Stunde kosten, kann die Differenz zwischen 50 und 250
Stunden schon ziemlich matchentscheidend sein.
Natürlich kommt es auch immer aufs Umfeld an, in dem man sich bewegt.
Bei IT-Dienstleistern liegt Java klar vorne (S. z.B. hier:
http://www.heise.de/developer/meldung/Umfrage-Java-ist-verbreitetste-Programmiersprache-bei-IT-Dienstleistern-1198249.html),
während im high performance computing Bereich C/C++ vermutlich seinen
Platz noch lange halten wird.
-stef
Stefan Werner
Apr 21, 2012, 1:46:13 AM4/21/12
to
Am 20.04.12 13:24, schrieb Felix Rauch:
Warnmeldung kommt, das Auto aber problemlos läuft, dann stöpseln sie
ihren Computer ein, setzen die Warnmeldung zurück und sagen, es sei
jetzt repariert :-)
Glücklicherweise verlangen sie dafür auch nichts....
Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht
geht. Ist in 90% der Fälle die beste Reparaturmethode :-)
-stef
> Stefan Werner<009w...@sneakemail.com> wrote:
> [...]
>> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
>> immer mehr zum Spezialisten.
>
> Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> muss auch noch die richtige Software haben um das Auto zu debuggen :-/
Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> [...]
>> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
>> immer mehr zum Spezialisten.
>
> Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> muss auch noch die richtige Software haben um das Auto zu debuggen :-/
Warnmeldung kommt, das Auto aber problemlos läuft, dann stöpseln sie
ihren Computer ein, setzen die Warnmeldung zurück und sagen, es sei
jetzt repariert :-)
Glücklicherweise verlangen sie dafür auch nichts....
Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht
geht. Ist in 90% der Fälle die beste Reparaturmethode :-)
-stef
Patrick Kormann
Apr 21, 2012, 10:40:20 AM4/21/12
to
Am 21.04.12 07:43, schrieb Stefan Werner:
> Also da muss ich jetzt doch mal eine Lanze brechen: Das hängt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
> sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
> unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
> wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
> etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst wäre es
> nicht mehr systemunabhängig)
Hast du mir ein Beispiel für ne App, die darin geschrieben ist?
> Also da muss ich jetzt doch mal eine Lanze brechen: Das hängt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
> sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
> unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
> wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
> etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst wäre es
> nicht mehr systemunabhängig)
Patrick Kormann
Apr 21, 2012, 12:27:17 PM4/21/12
to
Am 21.04.12 07:46, schrieb Stefan Werner:
> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> Warnmeldung kommt, das Auto aber problemlos läuft, dann stöpseln sie
> ihren Computer ein, setzen die Warnmeldung zurück und sagen, es sei
> jetzt repariert :-)
> Glücklicherweise verlangen sie dafür auch nichts....
Bei uns geht der Fehler meist irgendwann von selbst wieder weg.
Ärgerlicher all die getauschten Glühbirnen, die gar nicht durchgebrannt
waren, sondern nur vom Bordcomputer gemeldet werden. Man kann das beim
Anmelden des Autos noch so oft sagen, die wechseln es trotzdem. Wenn
dafür dann noch die Hundebox ausgebaut wird, um so schlimmer.
Das ganze kam von einem schlechten Kontakt bei der Fassung her, inkl.
weggeschmortem Kontakt. Irgendwann hab ich das dann mal irgendwie
'geflickt'.
> Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht
> geht. Ist in 90% der Fälle die beste Reparaturmethode :-)
Aber unbefriedigend, irgendwie. Vor allem wenn man dann im Internet so
tips liest wie 'wenn plötzlich ein Fehler des ESP gemeldet wird, liegt
das meist am Bremsschalter'.
> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> Warnmeldung kommt, das Auto aber problemlos läuft, dann stöpseln sie
> ihren Computer ein, setzen die Warnmeldung zurück und sagen, es sei
> jetzt repariert :-)
> Glücklicherweise verlangen sie dafür auch nichts....
Ärgerlicher all die getauschten Glühbirnen, die gar nicht durchgebrannt
waren, sondern nur vom Bordcomputer gemeldet werden. Man kann das beim
Anmelden des Autos noch so oft sagen, die wechseln es trotzdem. Wenn
dafür dann noch die Hundebox ausgebaut wird, um so schlimmer.
Das ganze kam von einem schlechten Kontakt bei der Fassung her, inkl.
weggeschmortem Kontakt. Irgendwann hab ich das dann mal irgendwie
'geflickt'.
> Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht
> geht. Ist in 90% der Fälle die beste Reparaturmethode :-)
tips liest wie 'wenn plötzlich ein Fehler des ESP gemeldet wird, liegt
das meist am Bremsschalter'.
Markus Grob
Apr 21, 2012, 6:53:18 PM4/21/12
to
Patrick Kormann schrieb:
> Und relativ schnell war es auch noch, auch wenn gewisse Fastloader aus
> dem 1541 ja auch schon einiges raus holten ;)
Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
Gruss, Markus, den Keller noch gefüllt haben mit Hard- und Software.
> Und relativ schnell war es auch noch, auch wenn gewisse Fastloader aus
> dem 1541 ja auch schon einiges raus holten ;)
dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
Gruss, Markus, den Keller noch gefüllt haben mit Hard- und Software.
Markus Grob
Apr 21, 2012, 6:59:54 PM4/21/12
to
Stefan Werner schrieb:
> Also da muss ich jetzt doch mal eine Lanze brechen: Das hängt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
Ich stimme für Qt ;-)
Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
liebe Mühe hat ;-)
> Also da muss ich jetzt doch mal eine Lanze brechen: Das hängt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> für AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
liebe Mühe hat ;-)
Patrick Kormann
Apr 21, 2012, 7:03:42 PM4/21/12
to
Am 22.04.12 00:53, schrieb Markus Grob:
> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
Naja, waren auch einige Daten weniger ;)
Aber ich meinte mehr so Hardwarelösungen die das Laden etc.
verschnellerten. Das hatte ich nie.
Es gab ja sowas Lösungen die Disketten komplett in ein RAM luden. So
viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144 KB?
> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
Aber ich meinte mehr so Hardwarelösungen die das Laden etc.
verschnellerten. Das hatte ich nie.
Es gab ja sowas Lösungen die Disketten komplett in ein RAM luden. So
viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144 KB?
Markus Grob
Apr 21, 2012, 8:36:13 PM4/21/12
to
Patrick Kormann schrieb:
> Es gab ja sowas Lösungen die Disketten komplett in ein RAM luden. So
> viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144
> KB?
Das waren 360kB für beide Seiten. Eine Seite hatte also um die 180kB.
Evtl. auch nur 170.
Gruss, Markus
> Am 22.04.12 00:53, schrieb Markus Grob:
>
>> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
>> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
>
> Naja, waren auch einige Daten weniger ;)
Nene, hochgerechnet.
>
>> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
>> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
>
> Naja, waren auch einige Daten weniger ;)
> Es gab ja sowas Lösungen die Disketten komplett in ein RAM luden. So
> viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144
> KB?
Evtl. auch nur 170.
Gruss, Markus
Stefan Werner
Apr 22, 2012, 1:35:12 AM4/22/12
to
Stefan Werner
Apr 22, 2012, 1:39:31 AM4/22/12
to
Am 22.04.12 00:59, schrieb Markus Grob:
Und ich dachte, Qt sei ein C++ - Framework (also objektorientiert).
Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen
Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz
übernehmen?
-stef
Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen
Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz
übernehmen?
-stef
Patrick Kormann
Apr 22, 2012, 7:18:30 AM4/22/12
to
Am 22.04.12 07:35, schrieb Stefan Werner:
> Eclipse (www.eclipse.org)
Hab da die Tage kurz reingeschaut aber wusste schon nicht welche Version
ich runterladen soll. Aber ich meinte mehr ne 'Enduser' APP und nicht
die Entwicklungsumgebung ;)
> Eclipse (www.eclipse.org)
Hab da die Tage kurz reingeschaut aber wusste schon nicht welche Version
ich runterladen soll. Aber ich meinte mehr ne 'Enduser' APP und nicht
die Entwicklungsumgebung ;)
Patrick Kormann
Apr 22, 2012, 7:17:05 AM4/22/12
to
Am 22.04.12 02:36, schrieb Markus Grob:
> Nene, hochgerechnet.
Ach so. Naja, Disketten waren IMHO immer ne PITA, egal auf welchem System.
> Das waren 360kB für beide Seiten. Eine Seite hatte also um die 180kB.
> Evtl. auch nur 170.
Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
> Nene, hochgerechnet.
Ach so. Naja, Disketten waren IMHO immer ne PITA, egal auf welchem System.
> Das waren 360kB für beide Seiten. Eine Seite hatte also um die 180kB.
> Evtl. auch nur 170.
Felix Rauch
Apr 22, 2012, 11:14:28 PM4/22/12
to
[...]
> > Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
> > Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
> > Evtl. auch nur 170.
> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
Englische kB sind eben etwas kleiner, wie yards vs Meter und so ;-)
> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
Felix Rauch
Apr 22, 2012, 11:20:07 PM4/22/12
to
Stefan Werner <009w...@sneakemail.com> wrote:
> Am 20.04.12 13:24, schrieb Felix Rauch:
> > Stefan Werner<009w...@sneakemail.com> wrote:
> > [...]
> >> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
> >> immer mehr zum Spezialisten.
> >
> > Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> > muss auch noch die richtige Software haben um das Auto zu debuggen :-/
> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> Warnmeldung kommt, das Auto aber problemlos l?uft, dann st?pseln sie
> Am 20.04.12 13:24, schrieb Felix Rauch:
> > Stefan Werner<009w...@sneakemail.com> wrote:
> > [...]
> >> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
> >> immer mehr zum Spezialisten.
> >
> > Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> > muss auch noch die richtige Software haben um das Auto zu debuggen :-/
> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> ihren Computer ein, setzen die Warnmeldung zur?ck und sagen, es sei
> jetzt repariert :-)
Meine eine Reparaturwerkstatt hat auch schon gesagt, dass sie das
Problem nicht weiter debuggen koennen, weil Holden die dazu noetige
Software noch nicht zur Verfuegung stellt. Anscheinend machen sie
das erst nach einigen Jahren. Allerdings war das auch eine lokale
Werkstatt, die nicht auf Holden spezialisiert war.
Felix Rauch
Apr 22, 2012, 11:24:00 PM4/22/12
to
Patrick Kormann <sir...@hotmail.com> wrote:
> Am 20.04.12 13:23, schrieb Felix Rauch:
> > Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> > lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> > hatte man selber direkt zur Verfuegung :-)
> Ja aber der Atari... b?h.. :)
> Am 20.04.12 13:23, schrieb Felix Rauch:
> > Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> > lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> > hatte man selber direkt zur Verfuegung :-)
> Aber ernsthaft, das k?nnte man ja heute genau so machen. Nur irgendwie
> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
> besser um die Eigenheiten der Hardware als der Programmierer.
Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> besser um die Eigenheiten der Hardware als der Programmierer.
ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
haben moechte in den Bildschirmspeicher schreiben und das war's
dann schon.
> Und
> sp?testens mehrere Cores gleichm?ssig zu befeuern d?rfte manuell echt
> kompliziert werden.
Ich denke man gibt jedem core einen Pointer auf den Code, den er
ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
dann schon etwas komplizierter werden.
Felix Rauch
Apr 22, 2012, 11:30:59 PM4/22/12
to
Stefan Werner <009w...@sneakemail.com> wrote:
> Am 20.04.12 15:32, schrieb Mario Rothacher:
> > Patrick Kormann wrote:
> >> Am 20.04.12 13:23, schrieb Felix Rauch:
> >>
> >>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> >>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> >>> hatte man selber direkt zur Verfuegung :-)
> >>
> Am 20.04.12 15:32, schrieb Mario Rothacher:
> > Patrick Kormann wrote:
> >> Am 20.04.12 13:23, schrieb Felix Rauch:
> >>
> >>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> >>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> >>> hatte man selber direkt zur Verfuegung :-)
> >>
> >> Ja aber der Atari... b?h.. :)
> >> Aber ernsthaft, das k?nnte man ja heute genau so machen. Nur irgendwie
> >> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
> >> besser um die Eigenheiten der Hardware als der Programmierer. Und
> >> sp?testens mehrere Cores gleichm?ssig zu befeuern d?rfte manuell echt
> >> besser um die Eigenheiten der Hardware als der Programmierer. Und
> >> kompliziert werden.
> >
> > Normalerweise l?uft ein Programm in n-threads. Jeder einzelner Thread
> > wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> ?bernimmst, also das OS aussen vor l?sst (d.h. eigentlich: Dein eigenes
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich l?uft das Programm dann nur auf einem Core und die
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> anderen h?ngen faul in der Gegend rum.
Grundsaetzlich hat doch jeder Core einen unabhaengigen PC (program
counter). Wenn der auf etwas sinnvolles zeigt, dann fuehrt der core
das dort stehende Programm aus. Was beim booten passiert, bin ich
allerdings nicht ganz sicher. Ob nur ein core per default anfaengt
etwas auszufuehren, oder alle gleichzeitig bei Adresse 0 starten
und dann aufgrund ihrer core-Nummer irgendwann stoppen, weiss ich
nicht mehr (ich hatte mir den entsprechenden boot-code im Linux kernel
mal angeschaut, ist aber schon lange her).
Stefan Werner
Apr 23, 2012, 1:09:13 AM4/23/12
to
Am 22.04.12 13:18, schrieb Patrick Kormann:
Eclipse ist nicht nur eine Entwicklungsumgebung, sondern auch eine
Plattform. RCP - Rich Client Platform.
Hier sind einige Beispiele für darauf basierende Apps:
http://www.eclipse.org/community/rcpos.php (Frei/OpenSource)
http://www.eclipse.org/community/rcpcp.php (Kommerziell)
Prominent ist z.B. Lotus Symphony (Ich wette Du hättest das nicht als
Java-Anwendung bezeichnet)
Relativ bekannt ist auch Azureus.
Aus der Schweiz das bsi-crm
http://www.bsiag.com/de/produkte/bsi-crm.html
Ich weiss ja nicht was für eine Art von Enduser-Apps Du gerne hättest.
Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
fast jedem Bereich was. Von natürlich sehr unterschiedlicher Qualität, klar.
-stef
Plattform. RCP - Rich Client Platform.
Hier sind einige Beispiele für darauf basierende Apps:
http://www.eclipse.org/community/rcpos.php (Frei/OpenSource)
http://www.eclipse.org/community/rcpcp.php (Kommerziell)
Prominent ist z.B. Lotus Symphony (Ich wette Du hättest das nicht als
Java-Anwendung bezeichnet)
Relativ bekannt ist auch Azureus.
Aus der Schweiz das bsi-crm
http://www.bsiag.com/de/produkte/bsi-crm.html
Ich weiss ja nicht was für eine Art von Enduser-Apps Du gerne hättest.
Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
fast jedem Bereich was. Von natürlich sehr unterschiedlicher Qualität, klar.
-stef
Stefan Werner
Apr 23, 2012, 1:20:24 AM4/23/12
to
Am 23.04.12 07:09, schrieb Stefan Werner:
> Ich weiss ja nicht was für eine Art von Enduser-Apps Du gerne hättest.
> Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
> fast jedem Bereich was. Von natürlich sehr unterschiedlicher Qualität,
> klar.
Um Dir die nächste Enttäuschung zu ersparen: Auf MacOS Lion ist die Java
Runtime nicht mehr standardmässig dabei. Die Apps werden also vermutlich
nicht laufen.
Man kann es aber leicht nachinstallieren:
http://support.apple.com/kb/DL1515?viewlocale=en_US&locale=en_US
Dann müsste es gehen.
-stef
> Ich weiss ja nicht was für eine Art von Enduser-Apps Du gerne hättest.
> Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
> fast jedem Bereich was. Von natürlich sehr unterschiedlicher Qualität,
> klar.
Runtime nicht mehr standardmässig dabei. Die Apps werden also vermutlich
nicht laufen.
Man kann es aber leicht nachinstallieren:
http://support.apple.com/kb/DL1515?viewlocale=en_US&locale=en_US
Dann müsste es gehen.
-stef
Stefan Werner
Apr 23, 2012, 5:39:07 AM4/23/12
to
Am 23.04.12 05:14, schrieb Felix Rauch:
quarterbyte, wobei 12 qb ein pb sind oder umgekehrt und 928 qb sind dann
ein mb (megabyte) und eine billion mb sind ein tb. Und das wiegt
getrocknet exakt 238 Unzen.
Dies nur zur Klarstellung.
-stef
> Patrick Kormann<sir...@hotmail.com> wrote:
>> Am 22.04.12 02:36, schrieb Markus Grob:
> [...]
>>> Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
>>> Evtl. auch nur 170.
>
>> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
>
> Englische kB sind eben etwas kleiner, wie yards vs Meter und so ;-)
Ja, es heisst aber auch nicht kilobyte, sondern poundbyte und
>> Am 22.04.12 02:36, schrieb Markus Grob:
> [...]
>>> Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
>>> Evtl. auch nur 170.
>
>> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
>
> Englische kB sind eben etwas kleiner, wie yards vs Meter und so ;-)
quarterbyte, wobei 12 qb ein pb sind oder umgekehrt und 928 qb sind dann
ein mb (megabyte) und eine billion mb sind ein tb. Und das wiegt
getrocknet exakt 238 Unzen.
Dies nur zur Klarstellung.
-stef
Patrick Kormann
Apr 23, 2012, 7:06:09 AM4/23/12
to
Am 23.04.12 07:09, schrieb Stefan Werner:
> Prominent ist z.B. Lotus Symphony (Ich wette Du hättest das nicht als
> Java-Anwendung bezeichnet)
Ja, kenne ich zwar nicht, aber das könnte ich mir vorstellen, dass ich
> Java-Anwendung bezeichnet)
das nicht als Java App bezeichnen würde.
> Relativ bekannt ist auch Azureus.
> Ich weiss ja nicht was für eine Art von Enduser-Apps Du gerne hättest.
> Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
> fast jedem Bereich was. Von natürlich sehr unterschiedlicher Qualität,
> klar.
stinkt.
Zu deinem anderen Posting: Natürlich hab ich die Java Runtime
installiert (installieren müssen...). Ich würde ja nicht gegen Java
meckern, wenn ich nicht allzu oft darunter leiden würde ;)
Patrick Kormann
Apr 23, 2012, 7:09:10 AM4/23/12
to
Am 23.04.12 05:24, schrieb Felix Rauch:
> Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> haben moechte in den Bildschirmspeicher schreiben und das war's
> dann schon.
Naja, ohne OS kannst du das immer noch - nur nicht so einfach, wenn's
dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man
halt die Hardware kennen.
> Ich denke man gibt jedem core einen Pointer auf den Code, den er
> ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
> man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
> abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
> dann schon etwas komplizierter werden.
Das auch, aber auch 4 Cores jederzeit mit unabhängigem Code so zu
befeuern, dass man auch was davon hat.. Das möchte ich nicht managen...
> Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> haben moechte in den Bildschirmspeicher schreiben und das war's
> dann schon.
dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man
halt die Hardware kennen.
> Ich denke man gibt jedem core einen Pointer auf den Code, den er
> ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
> man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
> abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
> dann schon etwas komplizierter werden.
befeuern, dass man auch was davon hat.. Das möchte ich nicht managen...
Markus Grob
Apr 23, 2012, 10:32:06 AM4/23/12
to
Stefan Werner schrieb:
> Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen
> Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz
> übernehmen?
Ich meine, es ist dual lizenziert.
http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
GPL oder kommerziell.
Gruss, Markus
> Am 22.04.12 00:59, schrieb Markus Grob:
>> Ich stimme für Qt ;-)
>>
>> Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
>> liebe Mühe hat ;-)
>
> Und ich dachte, Qt sei ein C++ - Framework (also objektorientiert).
Dies stimmt, doch eben c und nicht java ;-)
>>
>> Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
>> liebe Mühe hat ;-)
>
> Und ich dachte, Qt sei ein C++ - Framework (also objektorientiert).
> Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen
> Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz
> übernehmen?
http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
GPL oder kommerziell.
Gruss, Markus
Stefan Werner
Apr 24, 2012, 2:32:27 AM4/24/12
to
Am 23.04.12 16:32, schrieb Markus Grob:
> Stefan Werner schrieb:
>
Vorher brauchte man praktisch einen Anwalt, um rauszufinden, ob man Qt
für ein bestimmtes Projekt nun verwenden darf oder nicht, deswegen habe
ich es seinerzeit nach einem Blick auf die Lizenzbedingungen nie mehr
näher angeschaut.
-stef
> Stefan Werner schrieb:
>
> Ich meine, es ist dual lizenziert.
> http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
> GPL oder kommerziell.
Ok, Seit 4.5 scheint es LGPL zu sein, dann ist es jetzt einfacher.
> http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
> GPL oder kommerziell.
Vorher brauchte man praktisch einen Anwalt, um rauszufinden, ob man Qt
für ein bestimmtes Projekt nun verwenden darf oder nicht, deswegen habe
ich es seinerzeit nach einem Blick auf die Lizenzbedingungen nie mehr
näher angeschaut.
-stef
Felix Rauch
Apr 25, 2012, 12:05:42 AM4/25/12
to
Patrick Kormann <sir...@hotmail.com> wrote:
> Am 23.04.12 05:24, schrieb Felix Rauch:
> > Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> > ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> > haben moechte in den Bildschirmspeicher schreiben und das war's
> > dann schon.
> Naja, ohne OS kannst du das immer noch - nur nicht so einfach, wenn's
> dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man
> halt die Hardware kennen.
Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
> Am 23.04.12 05:24, schrieb Felix Rauch:
> > Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> > ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> > haben moechte in den Bildschirmspeicher schreiben und das war's
> > dann schon.
> Naja, ohne OS kannst du das immer noch - nur nicht so einfach, wenn's
> dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man
> halt die Hardware kennen.
den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
abbilden, aber ich bin da kein Experte...
> > Ich denke man gibt jedem core einen Pointer auf den Code, den er
> > ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
> > man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
> > abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
> > dann schon etwas komplizierter werden.
> befeuern, dass man auch was davon hat.. Das m?chte ich nicht managen...
Hm ja, das braucht ein Bisschen was... aber mit mutexes und so kommen sich
die Prozessoren dann schonmal nicht mehr in die Quere in kritischen
Bereichen und wie man die Arbeit sonst aufteilt, kommt halt auf die
Anwendung drauf an.
Patrick Kormann
Apr 25, 2012, 7:19:57 AM4/25/12
to
Am 25.04.12 06:05, schrieb Felix Rauch:
> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
> abbilden, aber ich bin da kein Experte...
Hm, war es nicht so, dass in der Intel-Welt das Zeugs noch nie 'memory
mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's
doch irgendwelche speziellen I/O Kommandos.
Jedenfalls müsste man heute noch genau so im Textmodus was auf die Karte
kriegen wie damals. DOS weiss schliesslich nichts von PCI...
> Hm ja, das braucht ein Bisschen was... aber mit mutexes und so kommen sich
> die Prozessoren dann schonmal nicht mehr in die Quere in kritischen
> Bereichen und wie man die Arbeit sonst aufteilt, kommt halt auf die
> Anwendung drauf an.
Ja, multi-Core macht ja auch nicht für jede Anwendung Sinn.
> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
> abbilden, aber ich bin da kein Experte...
mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's
doch irgendwelche speziellen I/O Kommandos.
Jedenfalls müsste man heute noch genau so im Textmodus was auf die Karte
kriegen wie damals. DOS weiss schliesslich nichts von PCI...
> Hm ja, das braucht ein Bisschen was... aber mit mutexes und so kommen sich
> die Prozessoren dann schonmal nicht mehr in die Quere in kritischen
> Bereichen und wie man die Arbeit sonst aufteilt, kommt halt auf die
> Anwendung drauf an.
Stefan Werner
Apr 25, 2012, 4:26:30 PM4/25/12
to
Am 25.04.12 13:19, schrieb Patrick Kormann:
Disk ins Laufwerk eines aktuellen Windows-PC geschoben und neu
gestartet. DOS bootete nicht. Ich weiss allerdings nicht woran es lag
und hatte auch nicht wirklich Lust lang rumzuprobieren. Aber könnte es
nicht sein, dass DOS einen aktuellen PC tatsächlich gar nicht mehr
booten kann?
-stef
> Am 25.04.12 06:05, schrieb Felix Rauch:
>
>> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
>> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
>> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
>> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
>> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
>> abbilden, aber ich bin da kein Experte...
>
> Hm, war es nicht so, dass in der Intel-Welt das Zeugs noch nie 'memory
> mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's
> doch irgendwelche speziellen I/O Kommandos.
> Jedenfalls müsste man heute noch genau so im Textmodus was auf die Karte
> kriegen wie damals. DOS weiss schliesslich nichts von PCI...
Also ich hab vor einigen Monaten mal spasseshalber meine treue DOS 3.3
>
>> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
>> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
>> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
>> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
>> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
>> abbilden, aber ich bin da kein Experte...
>
> Hm, war es nicht so, dass in der Intel-Welt das Zeugs noch nie 'memory
> mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's
> doch irgendwelche speziellen I/O Kommandos.
> Jedenfalls müsste man heute noch genau so im Textmodus was auf die Karte
> kriegen wie damals. DOS weiss schliesslich nichts von PCI...
Disk ins Laufwerk eines aktuellen Windows-PC geschoben und neu
gestartet. DOS bootete nicht. Ich weiss allerdings nicht woran es lag
und hatte auch nicht wirklich Lust lang rumzuprobieren. Aber könnte es
nicht sein, dass DOS einen aktuellen PC tatsächlich gar nicht mehr
booten kann?
-stef
Patrick Kormann
Apr 25, 2012, 4:56:42 PM4/25/12
to
Am 25.04.12 22:26, schrieb Stefan Werner:
> Also ich hab vor einigen Monaten mal spasseshalber meine treue DOS 3.3
> Disk ins Laufwerk eines aktuellen Windows-PC geschoben und neu
> gestartet. DOS bootete nicht. Ich weiss allerdings nicht woran es lag
> und hatte auch nicht wirklich Lust lang rumzuprobieren. Aber könnte es
> nicht sein, dass DOS einen aktuellen PC tatsächlich gar nicht mehr
> booten kann?
Also ich hab auf meinem Mac noch nicht lang irgend ein DOS gebootet
(FreeDOS oder sowas) für irgend ein Firmwareupgrade. Das ist aber noch
ein Core2Duo. (Hab auch i7, aber da hab ich's nicht probiert).
Doch, ich glaube das geht schon noch. War halt nicht von Disk sondern
von CD...
Auch das A20 Gate scheint im i7 noch zu sein...
> Also ich hab vor einigen Monaten mal spasseshalber meine treue DOS 3.3
> Disk ins Laufwerk eines aktuellen Windows-PC geschoben und neu
> gestartet. DOS bootete nicht. Ich weiss allerdings nicht woran es lag
> und hatte auch nicht wirklich Lust lang rumzuprobieren. Aber könnte es
> nicht sein, dass DOS einen aktuellen PC tatsächlich gar nicht mehr
> booten kann?
(FreeDOS oder sowas) für irgend ein Firmwareupgrade. Das ist aber noch
ein Core2Duo. (Hab auch i7, aber da hab ich's nicht probiert).
Doch, ich glaube das geht schon noch. War halt nicht von Disk sondern
von CD...
Auch das A20 Gate scheint im i7 noch zu sein...
0 new messages