Hallo Besucher, der Thread wurde 5,3k mal aufgerufen und enthält 29 Antworten

letzter Beitrag von sixtyfour am

Warum hat der C64 "nur" 38911 Bytes frei?

    Meine Frage im Titel ergab sich aus einer kleinen Unterhaltung in der Shoutbox.



    ShmendricDeutschland ist Scheisse... "Es wurden keine Städte mit der Postleitzahl "38911" gefunden. "


    Shmendric Spanien hat sowas


    oobdoo ist das wichtig?


    Shmendric Ja Klar ist das wichtig.


    Shmendric ich will in der stadt 38911 wohnen


    Shmendric das passt zu mir


    Shmendric du willst natürlich lieber die postleitzahl 464, schon klar.


    oobdoo tdann sollte ich in einer stadt mit 42249 wohnen


    oobdoo warum hat der cpc mehr freien speicher als ein 64er, obwohl der cpc allein 16kb nur für den bildschirmspeicher verschwendet?


    Das ist eine ernstgemeinte Frage.

    Zitat von C64-Wiki

    BASIC-RAM: BASIC-Benutzerspeicher (in diesem Bereich werden die BASIC-Programme nach dem Laden abgearbeitet, hier befinden sich auch alle Daten von Variablen und Feldvariablen). Dieser Speicher ist 38911 Bytes lang, wenn noch kein Programm geladen wurde.

    Für alle Details siehe bitte den Speicherbelegungsplan.

    Wobei in 64'er 12/89 Seite 67 ein Programm enthaten ist, welches den freien Basic-Speicher auf 50687 Bytes zu erhöhe. Funktioniert allerdings nur mit dem original CBM Kernal.


    Es funktionert grob so, dass der Basic-Interpreter an anderer Speicherposition reloziert wird und dann auf RAM umgeschaltet wird.


    BTW: Den Rekord hält glaub ich das Business Basic Modul für den C64: 61183 Bytes frei. Mit viel Bankswitching.

    Kurz und knapp: Weil das Commodore Basic 2.0 von maximal 40KByte RAM ausgeht.


    Weil es eben noch vom VC-20 übernommen wurde, und da war bei 40 Schluss...

    Ich versuch es mal, verdaulich und trotzdem korrekt zu erklären:


    Der C64 arbeitet mit einem 16bit Adressbus, damit lassen sich exakt 64 kiB adresssieren. Er hat zwar auch exakt diese 64 kiB an RAM... allerdings ist der Adressraum mehrfach belegt:


    - I/O funktioniert beim C64 "memory mapped", d.h. es gibt keine speziellen Instruktionen für die Kommunikation mit Peripherie sondern Register der entsprechenden Chips werden an bestimmten Adressen eingeblendet als ob sie RAM wären.


    - Es gibt zwei ROM Chips, einer für den kernal (betriebssystem), einer für das Basic.


    (vereinfacht, gibt noch character rom, color ram, expansion module .. lassen wir das hier *g*)


    Zu dem zweck sind die obersten 3 8kiB bänke umschaltbar zwischen RAM und anderen konfigurationen: per default liegt ganz oben der kernal, in der vorletzten bank der I/O bereich (nur 4 kiB, die andere Hälfte ist immer RAM, aber von Basic nicht nutzbar) und in der drittletzten Bank liegt Basic. Damit fallen schon mal 24 kiB weg, bleiben 40.


    Davon sind jetzt noch die untersten 2 kiB fürs System reserviert ("zeropage", stack, puffer, sprungvektoren, und der bildschirmspeicher), bleiben also 38kiB.

    Zitat von oobdoo

    oobdoo warum hat der cpc mehr freien speicher als ein 64er, obwohl der cpc allein 16kb nur für den bildschirmspeicher verschwendet?


    Das ist eine ernstgemeinte Frage.

    Dann eine ernstgemeinte Antwort darauf: Weil das CPC-BASIC (und OS) Bankswitching beherrscht, und das des C64 nicht. Warum nicht? Weil der C64 ein mit der heißen Nadel gestrickter Joghurtbecher ist; grad mal zwei Monate von der Idee (den neuen Chipsatz plus 64K RAM in den gescheiterten VIC-40 zu setzen) bis zur Messevorstellung sind schon mehr als sportlich; in dem halben Jahr bis zur Auslieferung kam dann nochmal ein komplettes Redesign dazu...


    Und warum hat man das BASIC nicht bei $c000 gelassen wie beim VC20? Dann hätte man wenigstens die IO-Chips direkt drunter legen können udn hätte 4K zusätzliches RAM gehabt? Klingt gut- man hat sich aber für die Speicheraufteilung des Atari 800 entscjieden, mit 8K Modul-ROM bei 8000 und A000 (letzteres dann normalerweise mit dem BASIC-Interpreter belegt) und dem IO bei D000. Das erlaubt einem 'richtigen' Programm, RAM bis CfFFF (=50K frei!) zu haben und trotzdem die IO und Kernal Funktionen ohne Umschaltung zu nutzen. Und man hat beide Modul-ROM-Bereiche direkt hintereinander, sodaß 16K große Module 'am Stück' programiert werden können.


    Immerhin gab das immer noch 10K mehr BASIC-Speicher als beim VC20, mehr als beim Atari 800 (vor allem wenn der ein DOS geladen hatte!), und die RAM-'Insel' bei C000 wurde im realen Betrieb ja auch oft und gerne für diverse Hilfsprogramme genutzt- ohne Gehampel mit RAMTOP wie bei den Sinclair-Rechnern, RESET-fest und insgesamt ziemlich praktisch.


    Zitat von Shmendric

    Weil das Commodore Basic 2.0 von maximal 40KByte RAM ausgeht

    Nö, dem ist das ziemlich egal. Es kann halt bis zum 3.5 kein Bankswitching und hat auf PET und VC20 mit dem Bildschirm-/IO-Speichre als hartes Limit zu kämpfen.

    Zitat von Shmendric

    vom VC-20 übernommen wurde,

    ...der nur max. 28K frei hatte... (wenn man nicht auf die Idee kam, 8K RAM in den Modulbereich bei A000 zu legen, den Stringspeicher dorthin zu verschieben und den IO-Block mit einem großen Pseudo-Array zu blockieren)

    Zitat von zrs1

    sind die obersten 3 8kiB bänke umschaltbar

    Öhm... nö. Je 8K bei 32, 40 und 56K (Modul, BASIC/Modul sowie Kernal) und 4K bei 52K (Char/IO). Wenn kein Modul steckt, ist bei 32K immer RAM. Und die Bereiche sind auch nicht unabhängig schaltbar, weil drei Prozessor-Port-Bits vier Bereiche auf RAM umschalten sowie zwischen IO und Char-ROM wählen müssen.

    Mach doch bitte nocht so'n Umweg! Kurz und bündig: RAM = "Arbeitsspeicher", von dem der Cevie sowie auch der 800XL 65536 bytes adressieren kann. Ein gewisser Teil wird durch den Interpreter gebraucht und ein anderer vom Disk Operating System genutzt. Der Rest ist beim Cevie eben die 38911 Bytes, beim Atari ohne DOS geringfügig mehr (mit DOS etwa 32 kBytes - wenn ich mich korrekt erinnere)! So jedenfalls war es mir mal dokumentiert worden

    Zitat von Obelix 20960

    Mach doch bitte nocht so'n Umweg!

    Naja du kannst es ganz genau machen und ungefähr ein Buchkapitel füllen. Oder du kannst es nur so ganz grob in einem Absatz erklären. Oder du versuchst eben einen Mittelweg zu gehen mit wenigstens ein paar Grundlagen ;)


    Übrigens wären 38 kiB eigentlich 38912 Bytes. Eines geht noch "verloren", weil der Basic-Speicher erst bei Adresse $801 = 2049 beginnt...

    Zitat von sixtyfour

    Wieso hat unser 8bit-Schätzchen einen 16bit-Adressbus?

    Weil sich 64K Adressen mit genau zwei Bytes darstellen lassen. Für längere Adressen bräuchte man drei Bytes und/oder verschiedene Adressierungsarten (siehe 8086, wohin das im Extremfall führt), mit kürzeren Adressen kann man nur kleinere Adreßräume direkt ansprechen (auch das gab es, typischerweise 32K insgesamt, die in 8K-'Pages' zerfallen); 64K waren also die bestmögliche Ausnutzung der Ressourcen ohne deutlich komplizierter zu werden. Prozessoren mit 6-bit oder 9-bit breiten Registern haben entsprechend andere 'optimale' Adreßräume.

    Zitat von Obelix 20960

    Ein gewisser Teil wird durch den Interpreter gebraucht

    All das ist aber auf dem CPC viel schlimmer- mehr Systemvariablen, 16K Bildschirmspeicher, 48K BASIC und Betriebssystem-ROM. Daß es auch auf Commodore-Maschinen anders geht, zeigt z.B. der Plus/4 mit 60K freiem Speicher.


    A prospos Buch schreiben: Brian Bagnall hat das in zwei Ausführungen getan. Wenn man das alles zuammenklaubt und die allerghrößten Ungenauigkeiten aussiebt, kommt eine sehr interessante Geschichte vom VIC-40 über den CBM-II bis zum Commodore 128 heraus, in der der C64 ursprünglich gar nicht vorkommt- und eigentlich nur deswegen existiert (noch dazu mit großem Erfolg) weil Jack Tramiel den absolut richtigen Riecher hatte.

    Hat der CPC jetzt ein besseres Speicherlayout als der C64 oder nicht?
    Oder belegen die Hardware-Register des CPC 464 bloß weniger Adressraum, bzw. hat der einfach "weniger Hardware zum Einblenden"? Die Vermutung liegt nahe, der CPC kann z.B. keine Hardware Sprites.


    Ist es überhaupt relevant, dass das OS (also, das Basic), Bank Switching kann? Der C64 kann auch Bank Switching, sogar mit Basic Pokes, z.B. für VIC Bänke oder das temporäre Einblenden des CharROMs anstelle des I/O-Bereichs. Man könnte die Ausführung dazu hier im Thread missverstehen.


    Außerdem wurde im Thread ja auch festgehalten, dass das Speicherlayout des C64 so unklug gar nicht ist mit Blick auf zusammenhängenden Programmspeicher und nutzbare $c000 Insel.


    Edit: Bei 8Bit-Rechnern mit 128kb RAM muss das OS vermutlich permanent bankswitchen, weil die CPU eben nur 64kb auf einmal sehen kann und man durch (wahrscheinlich interruptgesteuertes) Bank Switching so eine Art "quasi gleichzeitig verfügbare 128kb" hat. Also - Vermutung. Ich kenne mich mit den 128kb 8 Bittern nicht aus. Das steht aber doch bei 64KB-Rechnern noch nicht so wirklich zur Debatte, bzw. hätte diese nur unnötig verteuert und verkompliziert.