Vorneweg, ist nicht wirklich ein Fehler, ich fand es nur bemerkenswert,
Ich habe wohl lediglich eine aberteuerliche Kombination von Modulen in meinem Tieflader betrieben.
Mfg Jood
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Ruudi am
Vorneweg, ist nicht wirklich ein Fehler, ich fand es nur bemerkenswert,
Ich habe wohl lediglich eine aberteuerliche Kombination von Modulen in meinem Tieflader betrieben.
Mfg Jood
Ok. Details?
Mal Doof gefragt, hatte eigentlich schon mal jemand versucht größere Speicher im C64 zu verbauen?
Werden die angezeigt und kann, wenn, auf den erweiterten Speicher zugegriffen werden? Zum Beispiel mit Geos
Mal Doof gefragt, hatte eigentlich schon mal jemand versucht größere Speicher im C64 zu verbauen?
Werden die angezeigt und kann, wenn, auf den erweiterten Speicher zugegriffen werden? Zum Beispiel mit Geos
Meinst du vielleicht sowas wie GeoRAM? Im Wesentlichen arbeiten alle Erweiterungen mit Banking oder der Einblendung eines Speicherfensters. Da der linear ansprechbare Speicher bereits voll mit 64 KByte befüllt ist, kann ich mir mit "verbauen im C64" jetzt nicht wirklich etwas vorstellen.
Die üblichen RAM-Erweiterungen können hier nicht vom Standard-BASIC beansprucht werden. Ein adaptiertes BASIC könnte mehr RAM nutzen. Beispielsweise wie beim C128 Variablen und Strings in eine andere RAM-Bank ablegen.
Aber auch beim bestehenden Speicherlayout eines C64 kann man mehr heraus holen: Das Paradox-BASIC macht das ja so, das der Interpreter nach "oben" verschoben wird, damit dieser mehr durchgehenden Speicher nutzen kann (ohne den Interpreter in der Speicherverwaltung allzu extrem umschreiben zu müssen).
Ich habe durch das Business-Modul von Kingsoft 61183 Basic-Bytes free.
Ich hatte eigentlich gemeint die internen Speicherchips durch größere zu ersetzten (einen anderen Kernel zu nutzen hatte ich nicht bedacht, wäre aber eine Idee) wird aber alles nicht klappen da die Programme ja auch nicht dafür ausgelegt sind. War nur mal so ein Gedanke
Das Problem ist die 6510 CPU. Die kann nur 64K adressieren, egal ob du 64K, 128K oder 256K reinsteckst. Du bräuchtest wie schon gesagt wurde Zusatzhardware
die ein Bankswitching übernimmt. Dadurch kann der Prozessor aber dennoch immer nur 64K zur Zeit "sehen".
Er wird also egal wieviel eingesteckt ist immer die 38911 anzeigen?
Mal abgesehen davon das mehr sowieso nicht nutzbar ist ohne zusätzliche Hartware oder anderer CPU.
Bei dem ganzen Wissen hier wundert es mich das noch keiner einen neuen CPU erdacht hat der das kann.
Egal wie unnütz das auch sein mag
Er wird also egal wieviel eingesteckt ist immer die 38911 anzeigen?
Nein, siehe Post von 1Byte
Mal abgesehen davon das mehr sowieso nicht nutzbar ist ohne zusätzliche Hartware oder anderer CPU.
Bei dem ganzen Wissen hier wundert es mich das noch keiner einen neuen CPU erdacht hat der das kann.Egal wie unnütz das auch sein mag
Weil das dann kein C64 mehr ist. C65/MEGA65 hamma schon.
https://de.wikipedia.org/wiki/Commodore_65
Es gibt ausserdem solche Ansätze, die aber wenig genutzt werden.
C64 mit eingebauter 65816 Turbo Karte
Es möchte wohl keiner Software schreiben, die dann nur mit dieser Modifikation läuft.
Außer vielleicht es ist einigermaßen "official", wie z.B. die REU.
Wie Eingangs erwähnt vermute ich die Ursache in meiner Kombination der Module,
ich hatte einen Triple X-Pander genommen, und hinten noch eine Art Dual-Weiche
eingesteckt.
Bestückt war diese Konstruktion wie folgt:
- 1. Sidekick Zero
- 2. SysTest64
- 3. MMC64
- 4. CMD 1750 (REU)
Ich denke das beim Einschalten irgendein Signal zu spät kam, dadurch anfänglich
ein ROM ausgeblendet war, und mitten im Ramtest aktiv wurde, deshalb auch die
krumme Summe.
Interessant ist nur das es immer genau 41779 Bytes sind, egal wie oft man startet,
allerdings ist auch keine Eingabe möglich, der Cursor fehlt.
Ich fand das Bild nur interessant.
Mfg Jood
Ich denke es waren einfach zu wenige Module eingesteckt .
Evtl auch einfach sich mal die Speicherbelegung des C64 anschauen, dann versteht man auch, wie es zu den "38911 Bytes Free" kommt:
https://www.c64-wiki.de/wiki/Speicherbelegungsplan
wer es noch ausführlicher möchte:
Focko für jedes Bit Speicher geht eine Leitung von der CPU zu den RAMs.
Hat ein RAM Chip mehr Kapazität, hat er auch mehr Leitungen.
Der Prozessor vom C64 hat aber nicht mehr Leitungen, dh bei größeren Chips würden ein paar Leitungen unbenutzt bleiben und somit nicht der ganze Speicher der Chips ausgenutzt werden.
Interessant ist nur das es immer genau 41779 Bytes sind, egal wie oft man startet,
allerdings ist auch keine Eingabe möglich, der Cursor fehlt.
Ich fand das Bild nur interessant.
Das kannst du ganz einfach mit POKE643,52:POKE644,171:SYS64767 nachstellen.
Da werden wohl die Speicheradressen 643 + 644 überschrieben worden sein, oder es liegt Programmcode da. Der Bereich wird gerne mal dafür missbraucht.
Bei dem ganzen Wissen hier wundert es mich das noch keiner einen neuen CPU erdacht hat der das kann.
Ganz sicher haben sich Leutz (auch damals™ schon) überlegt, wie man dem C64 mehr Speicher spendieren könnte. Immer mit der gleichen Schlußfolgerung: ja, es geht - und man hat damit eine nicht-Standard-Hardware, bei der bestehende Programme (inkl. des originalen Betriebssystems!) nichts von dem neuen Speicher nutzen können und neue, angepaßte Programme nur eine sehr geringe Anzahl von geänderten Rechnern vorfinden, auf denen sie dann laufen würden. Insbesondere bei Änderungen auf der Hauptplatine gehen bei dieser Aussicht bei den meisten die Schotten zu.
Daß "ein- und derselbe" Rechner mit unterschiedlichem Speicherausbau daherkommen könnte ist nun selbst bei 8-Bit-CBMs nicht ungewöhnlich (siehe VC-20), beim C64 hatte man aber nun mal mit 64 KB die Speichermenge erreicht, welche die verbaute 6510 CPU ohne weitere Maßnahmen als ganzes adressieren kann. Entsprechend sind sogar die geringfügig flexibleren Speichergrößen-Abstraktionsmechanismen entfernt worden, die im VC-20 ROM noch drin waren - "weil ja ohnehin immer der gleiche Speicher da ist".
Heutzutage ist unterschiedlicher Speicherausbau bei ansonsten gleichen Rechnern was ganz normales und im Betriebssystem abstrahiert, das war aber zu der Zeit eben nicht selbstverständlich.
Alles anzeigenVorneweg, ist nicht wirklich ein Fehler, ich fand es nur bemerkenswert,
Ich habe wohl lediglich eine aberteuerliche Kombination von Modulen in meinem Tieflader betrieben.
Mfg Jood
Und der Cursor blinkt auch nicht
für jedes Bit Speicher geht eine Leitung von der CPU zu den RAMs.
Wow, das sind bei den 65536 Byte x 8Bit dann ja 524288 LEITUNGEN, wo die nur alle versteckt sind?
Um es klar zu machen: DRAM arbeitet mit nem gemultiplexten Adressbus, in Reihen und Spalten (über die Signale RAS und CAS)
somit braucht man für die Adressierung von 64KB = 2^16 Byte 8 Leitungen plus eben die beiden Auswahlleitungen.
Nimmt man 9 Leitungen, also eine mehr, ergibt sich schon 2^18 Byte Adressiermöglichkeiten, d.h. 256KB, mit 10 Leitungen dann 1MB usw usw.
Nur: am C64 werden eben nur 8 Leitungen am RAM angesprochen, d.h. wenn Du 256er RAMs einsetzt (2 oder 8 Stk, je nachdem, wieviele Bit eines Byte in einem Bautein stecken, üblich sind entweder ein Bit oder 4 Bit), dann müsstest Du die 9. Leitung fix auf GND oder 5V legen und damit wird aus dem 256er Baustein ein virtueller 64K-Baustein.
Kann helfen, wenn die 64K Rams mal überhaupt nicht mehr verfügbar sind, aber "bringen" tut es Null, Nix!
Wie oben schon mehrfach beschrieben, ist die gesamte Architektur auf 64K begrenzt, C= hat über die Mehrfachnutzung mit ausblendbarem ROM etc. eh schon viele Tricks angewandt, um das Maximum raus zu kitzeln. Mehr geht nur über Expanded Memory (EMM), wie man das am PC nannte, d.h. Banking. Davon muss aber jedes Progamm oder auch das Betriebssystem Bescheid wissen und einen solchen Standard hat es beim C64 ab Werk leider nie gegeben, erst Geos hat dann in der Spätzeit des C64 noch einen "Pseudo"-Standard dafür definiert, aber eben nur für reine Geos-Programme.
(die 17xx REU waren ein Versuch von Commodore, so einen Standard auch noch "nachzuliefern", aber kam zu spät, war technisch aufwändig und somit sehr teuer und aufgrund fehlender Unterstützung im Kernal und Basic sowiewo schon wieder nur unter Assembler oder über eigenerstellte Basic-Routinen rein für deren Daten nutzbar, dies aber auch nur rudimentär, da auch keine Unterstützung für nutzerdefinierte Variablentypen, insb. keine "ausgelagerten".)
n.B.: Eine Ausführung "normaler" C64 Programme unter Geos, so wie man das für Windows bis ME hinsichtlich von Dos-Programmen kannte (danach noch emuliert), das ging m.W.n. am C64 großteils nicht, möglicherweise wäre es für reine Basic-Programme machbar, aber das wären dann nicht unbedingt die "Interessanten" Programme...
Ruudi Experten haben festgestellt, dass man jede Leitung ein- und ausschalten kann. Pro Leitung 2 Zustände und 16 Leitungen können somit ca 64kB RAM ansprechen.
Zum Glück sind sie da drauf gekommen, bevor sie eine halbe Million Kabel verlegt haben
16 zur Adressierung, 8 für die Daten, um genau zu sein
Es gibt ausserdem solche Ansätze, die aber wenig genutzt werden.
C64 mit eingebauter 65816 Turbo Karte
Das gilt für alle 65816-basierten Erweiterungen, wie Flash-8, SuperCPU. Da hat die CPU einen linearen 24-Bit-Adressraum (16 MByte), wobei das RAM aber "außerhalb" des C64 befindet (also üblicherweise nicht im Blickfeld des VIC-II-Chips).
Je nach Modus und Adressierungsart ist, kann die CPU auf mehr als 64K zugreifen. Aber mit dem Standard-BASIC und -KERNAL ist das halt nicht kompatibel, also insofern, dass die von dem Speicherreichtum unmittelbar profitieren könnten. Die c't-Projekt-Entwicklung stellt beispielsweise das RAM als RAM-Disk zur Verfügungen. Auch eine Art Speicher der Standard-Umgebung als "Erweiterung" unterzujubeln.