Beiträge von mc71 im Thema „rom basierter pc?“

    @TePe: Das RAM-TOS der ersten Atari St wurde ganz normal in den Hauptspeicher geladen- damit waren schonmal 200k von den 156 weg. Das war IIRC der Hauptgrund für diese Krücke: Das TOS war noch zu groß für die vorgesehenen ROMs. Wenn man jetzt den BASIC-Interpreter startete (von Diskette natürlich) blieben gerade mal 10k oder sowas für das Programm über... andererseits blieb uns so der eigentlich geplante 130ST mit nur 128k RAM erspart.

    @sauhund: Ich hätte ja gedacht daß Du den KENBAK-1 ausgräbst und nciht so eine langweilige ARM-Kiste :crying:

    cbmhardware: HD-Floppy funzt schon, zumindest die 3,5-Zol-Version. Man brauicht aber DOS ab (iirc) 3.2 oder 3.3 um damit 720-K-Disks zu verarbeiten; darunter tun es aber auch DD-3,5er-Laufwerke nicht. HD-5 1/4 geht theoretscih, schreibt aber ein ekliges Mischformat das mit nix kompatibel ist.

    NEIN!

    VC20, IBM-PC, Amiga, atari ST da wird direkt aufs ROM zugegriffen.

    Vorsicht! Beim PC gilt das nur für die ersten; spätestens bei 386er mit Cache oder gar virtuellem EMS-Treiber ist das nicht mehr unbedingt der Fall. Udn der Amiga hatte anfangs das Kickstart im Write-Once-memory... das hatte zwar andere Gründe (Kick war noch nicht stabil genug, und man wollte nicht alle zwei Monate neue ROM-Sätze ausliefern.. )

    Beim TI99/4a war das so extrem das die Kiste 24 kB ROM und grad mal 256 Bytes CPU RAM hatte da musste man sogar die 16 kB VideoSpeicher für Programme verwenden.

    Das ist soweit falsch. Der TI99 sollte ursprünglich einen Ein-Chip-Mikrocontroller als CPU bekommen, dessen Auslieferung sich aber von Monat zu Monat verzögerte. Zunächst hat man daher diesen Chip mit dem 'dicken# TMS 9900 und den besagten 256 Bytes RAM nachgebaut; als sich herausstellte daß der vorgesehene Chip nicht kommen würde hat man dann dieses zunächstmal unsinnige Konzept beibehalten anstatt die Kiste noch einmal umzukonstruieren. Andere Systeme mit demselben Grafikchip waren zwar auch nicht überreichlich mit RAM bestückt, aber ein kleinwenig mehr war es schon...

    Reine Definitionssache. Laß Windows bis zum Desktop hochfahren, mach ein suspend-to-disk (Ruhzuistand genannt bei XP und Vista) und laß den Rechner zukünftig von diesem Speicherabbild starten (nein, genau das können aktuelle Windows-Versionen nicht, die verwerfen die Datei, sobald sie erfolgreich davon gestartet sind!) Nenne diesen vorgang 'booten', nenne das bisherige Booten 'Neuinitialisierung' oder sonst etwas Hippes. Problem gelöst. Für den Anwender ist es ja leidlich egal, was genau da abläuft; der will wissen wie lange er warten muß bis er mit dem Rechner arbeiten kann.

    Heutige ROMs sidn übrigens um Größenordnungen langsamer als RAM. Man hätte also kaum Freude an einem Programm, das wie das C64-BASIC direkt vom ROM liefe. Die reinen Datenmengen sidn es aber auch gar nicht, die den Botprozeß so lang machen; es sidn die aberhundert >Tests auf neue Hardware, das Auslesen der Verknüpfungen von Programmen mit ihren Dateitypen, die >Initialisierung diverser Hintergrund-Prozesse vom Virenscanner bis zum Treiber für die Digital-TV-Karte... alles Dinge, die im Prinzip nicht täglich neu gemacht werden müßten. Und genau da setzt halt die Idee an, den Rechner standardmäßig über suspend-to-disk abzuschalten...