2. RAM im Rechner

[Marco]

Da mein alter Casio CFX 9850G sowieso schon seit längerer Zeit kaputt ist, hab ich gestern mal das Display "abmontiert" (vielleicht wäre "abgerissen" zutreffender). Da hab ich drunter zwei Speicherchips mit je 28 Pins gefunden, LC2 und LC3. LC2 ist eins von Sanyo mit dem Aufdruck "LC3564SM-85", und LC3 von Toshiba mit der Aufschrift "TC55257DFL-85V".

Laut den Datenblättern sind beides RAM Module, und zwar ist das von Sanyo eins mit 256KBit (=32KB), also der "normale" RAM, wo Casio Basic Programme, Bilder, Listen, Variablen usw. gespeichert werden (dessen Image auf den PC übertragen wird, wenn man Backups sendet), aber das andere hat nur 64KBit = 8KB!

Ich weiß zwar nicht, ob dass schon mal jemandem aufgefallen ist (vielleicht hat ja noch niemand das Display "abgerissen"?), aber jedenfalls frag ich mich, wozu die zusätzlichen 8KB wohl gut sind.

Fakt ist, sie werden nur vom System verwendet (nur das 32KB Modul ist für den Benutzer gedacht), und es führen Leiterbahnen von diesem 2. Modul zu 2 Chips, von denen einer an die Längs - und einer an die Querseite des Displays angeschlossen ist (Zeilen - und Spaltencontroller des Displays?). In dem kleinen RAM ist also wahrscheinlich der Video RAM untergebracht, aber der würde nur 2 oder 4KB benötigen (128x64x2 Bit bzw. 128x64x4 Bit). Was ist mit dem Rest von mindestens 4KB?

Vielleicht bleiben sie ungenutzt, vielleicht befindet sich dort eine zweite Grafikspeicherseite, aber vielleicht werden sie von der CPU auch als Stack verwendet (was nicht so schön wäre; siehe Threat "Assembler ohne den ROM auszutauschen"), keine Ahnung. Hat vielleicht jemand nähere Informationen dazu?

PS: hab auch Fotos davon (aber noch nicht geuppt), damit niemand erst das Display seines Rechner "abreißen" muss.

[Marco]

Das mit dem 2. Orangeattribut stimmt zwar (steht auch unter http://www.pageofmarco.de/cfx4col.php3), erklärt aber die restlichen 4 KB trotzdem nicht:

Falls der Displayadapter die einzelnen Farbschichten (weiß, orange2, grün, blau, orange) in pixelweise Farbinformationen zu je 2 Bit (= 4 Möglichkeiten: weiß, grün, blau, ornage; orange2 sieht ja genau wie orange aus) konvertiert, hätten die Grafikdaten eine Größe von 128x64x2 Bit = 2KB.

Wenn er die einzelnen Farbschichten beibehällt (orange2, grün, blau und orange; weiß ist keine Farbschicht, sondern wenn alle 4 Farbschichten aus sind) werden 4 Bit pro Pixel gebraucht und die Grafikdaten hätten dann eine Größe von 4KB (ist übrigens bei den Bilddaten Pict1..Pict6 und dem Grafikfenster auch so).

Stack overflow erzeugen geht nicht - ich mein ja nicht den Casio Basic Stack, sondern den CPU Stack. Wir werdens wohl leider nie erfahren ... :(


[geändert von Marco am [TIME]1091290598[/TIME]]

[LameM]

Es kann doch auch schlicht daran liegen, den aufwand minimal zu halten, von 2kb s-rams gibts nen sprung auf 8kbyte, alles dazwischen ist ungebräuchlich und somit teuer und schlecht für massenproduktion...

deswegen werden die einfach nen 8kb typ reingesetzt haben...

Marian

[Marco]

^^ sehr gut möglich ...

[*hik]

Kann es sein, dass der Programmspeicher (CFX internes Betriebsystem) vom Datenspeicher(Programme, Daten) einfach getrennt sind. Damit Überschreiben des Programmspeichers verhindert werden kann. Sowas nennt man bei Mikrocontrollern als "Harvard-Architektur".

**************************
www.cfx9850.de.ms

[Maddix]

vlt. sind die paar kb für die progg-bibleotek gedacht? die könnten ja gezipt sein :?

[efi]

Erstellt von *hik

Kann es sein, dass der Programmspeicher (CFX internes Betriebsystem) vom Datenspeicher(Programme, Daten) einfach getrennt sind.

Nein, bzw. Nicht durchgängig. Ich habe es schon geschafft, durch diverse Manipulationen im RAM (Matritzen- also Datenbereich) die Bilder im CONICS-Menü zu verändern (in Pixelwirrwar).

Erstellt von Maddix
vlt. sind die paar kb für die progg-bibleotek gedacht? die könnten ja gezipt sein :?

Unwahrscheinlich, weil das ROM nicht teuer ist, und es ja auch ruck-zuck geht, die Daten ins RAM zu laden, wasbei Entschlüsselung sicher länger dauern würde... Aber sicher bin ich mir nicht... aber Das ELEMTAB-Programm würde ja auch bloß nicht vollständig in nen 4KB-Zwischenspeicher passen...

[Maddix]

Ich meine als Zwischenspeicher. Und bei größeren progs wirds halt gezipt!

[Marco]

Erstellt von hik

Kann es sein, dass der Programmspeicher (CFX internes Betriebsystem) vom Datenspeicher(Programme, Daten) einfach getrennt sind

Eigentlich nicht. Mach mal den RAM deines GTR fast voll und lass nur ein paar Byte (vielleicht 10) frei. Geh dann mal ins RUN Menü und gib etwas ein, das mehr als 5 aber weniger als 10 Bytes braucht (z.B. "2*(3+4)" ). Ergebnis: Mem Error. Würde das OS Daten für Operationen in einen anderen RAM auslagern, dürfte das eigentlich nicht sein, es ist also zumindest ziemlich wahrscheinlich, dass a) sowohl Stack als auch b) OS interne Daten in das 32KB Modul ausgelagert werden.

Es kann allerdings durchaus sein, dass einige vorinitialisierte, aber veränderliche Daten in diesen retlichen 4KB liegen, um sie vorm Überschreiben zu schützen.

Ertsellt von Maddix

vlt. sind die paar kb für die progg-bibleotek gedacht? die könnten ja gezipt sein

^^Auf keinen Fall des Rätsels Lösung. 1. hat der CFX 9850G ja überhaupt noch keine, 2. dürfte die wohl auch gezippt wesentlich > 4KB sein.

Erstellt von efi

Nein, bzw. Nicht durchgängig. Ich habe es schon geschafft, durch diverse Manipulationen im RAM (Matritzen- also Datenbereich) die Bilder im CONICS-Menü zu verändern (in Pixelwirrwar).

Kann mir allerdings nur vorstellen, dass durch die Manipulationen bestimmte Adressangaben im RAM nicht mehr gestimmt haben und so den Rechner zum Absturz / Fehlfunktionieren gebracht haben. Ich hatte vor einiger Zeit ja mal den kompletten RAM (also zumindest das 32KB Modul) analysiert, irgend welche Bilddaten habe ich da nicht gefunden (es wäre ja auch nicht besonders sinnvoll, ohnehin im ROM vorhandene Bilddaten in den RAM auszulagern und so Speicher zu verschwenden).

------------------------------------------------------------------

Also ich glaube,

a) entweder LameM hat Recht oder
b) *hik hat zumindest teilweise Recht oder
c) noch ne ganz neue Theorie (die ich mittlerweile für die wahrscheinlichste halte):

vom AFX weiß ich, dass er DEFINITIV mehrere Videoseiten verwendet. Auf einer wird das Hauptmenü dargestellt, und ruft man einen Untermenüpunkt auf, werden die aktive - / sichtbare Grafikseite umgeschalten (der Menüpunkt verwendet dann weiterhin die neue aktive / sichtbare Seite). Schaltet man mit der [Menu] - Taste ins Hauptmenü und geht dann wieder zurück zum vorherigen Menüpunkt, hat sich nichts verändert, d.h., der alte Videopufferinhalt wurde wieder hergestellt. Das wird beim AFX sehr effektiv realisiert durch Page Flipping - das Menü benutzt für die Grafik einen anderen Videopuffer als die Menüpunkte, und es werden nur die Adressen der Grafikseiten auf die entsprechenden Puffer umgeschalten (für den AFX stimmt das definitiv; habe das mit einem Assemblerprogramm überprüft, auf dem CFX geht das ja nicht).

Der CFX verhält sich genau so: schaltet man von einem Menüpunkt ins Hauptmenü und dann wieder zurück zum Menüpunkt, wird der Inhalt des Videopuffers wieder hergestellt. Ich vermute also:

Der CFX legt in den 8KB RAM 2 Videoseiten a 4KB ab.

[geändert von Marco am [TIME]1097240225[/TIME]]


[geändert von Marco am [TIME]1097240259[/TIME]]