Gängige Speichererweiterungen?

  • Ich hab mal eine dringende Frage: Was sind die gängigsten Speichererweiterungen und wie spricht man sie an (OUTs, Adressen) und wie unterscheiden diese sich zum Banking des 6128?


    Danke und Gruß,


    Brueggi

  • Ergänzung: Wie schalte ich vom Multiface die 8K ein/aus?

  • Mailzeit, Brueggi!


    Die gängigsten Speichererweiterungen waren die a la CPC6128, also dk'tronics und Dobbertin.


    Dazu hatte ich mal einen Artikel für den Rundschlag geschrieben / veröffentlicht / zu veröffentlichen vergessen; habe ihn Dir an Deine Yahoo-Adresse geschickt und auf ftp.cmo.de liegt er schon incoming.


    Viel Erfolg,
    AMSi

  • Zitat von "Tolkin"

    Haben nicht alle, bis auf Vortex und Otten und Fecht, versucht Ihre Speichererweiterungen DkTronics kompatibel zu machen?


    Eher wurde versucht, sie an den erweiterten Speicher des CPC6128 anzulehnen.


    Wen gab es denn da noch außer den nun in diesem Thread genannten?


    Die Inicron-Speichererweiterung kann nur 16 KB-Blöcke ab &4000 einblenden, dk'tronics, Dobbertin sowie die zweite Speicherbank des CPC6128 können da noch etwas mehr.


    Hatte Data Media eine Speichererweiterung? Und wenn ja: Hat irgend jemand von Data Media etwas gesehen, außer der Werbung in den frühen Ausgaben der Schneider CPC International?


    Oh, in der c't gab es, glaube ich, noch ein Projekt, den CPC6128 intern auf 512 KB aufzurüsten.


    Flopp und weg,
    AMSi

  • So wie ich das in Erinnerung habe, war die einzige relevante Alternative zur 6128/dk'troncis Kompatibilität die Vortex mit ihrem 2x32KB Banking. Das andere müssen ja echt totale Exoten gewesen sein, selbst die Vortex war aufgrund der Inkompatibilität nicht so stark gefragt. Und echt schade, daß die Inicron die anderen Bank-Modes (#c1,#c2, #c3) nicht kann.


    @Brüggie: Übrigens hat letztens erst ein Australier in der CSA8 sowas ähnliches gefragt:
    <!-- m --><a class="postlink" href="http://groups.google.com/group/comp.sys.amstrad.8bit/browse_thread/thread/96619419e6d9965b/">http://groups.google.com/group/comp.sys ... 9e6d9965b/</a><!-- m -->
    Da findest Du dann auch ne Menge Infos.


    CU,
    Prodatron

  • Erstmal vielen Dank für die ganzen infos.
    Ich bastel mir gerade einen kleinen Speichermanager (EXTMEM.SYS) - der so eine Art Himem.sys für Arme ist. Man kann bis jetzt Speicher anfordern, freigeben (max. 20 Anforderungen) - wobei der Speicher auch fragmentiert verwaltet wird - Speicherconfig auslesen (installierter RAM, freier RAM), und einen Transfer Bank 0<->Exp. Ram. erledigen. Das praktische: Er benötigt keinen Basic-RAM (HIMEM bleibt unverändert, nur ab B0D7 liegen ein paar Bytes, und in Bank $C4 nochmal 2K).


    Ach ja - ich hab das Ding mit dem aktuellen WinApe entwickelt. Meine Güte, das war wieder kurz vor dem Nervenzusammenbruch :P Nach 3 Stunden Fehlersuche hab ich erstmal den Assembler vom WinApe geprüft und siehe da...er ist (wie erwartet) fehlerhaft. Als Beweis hab ich erstmal Screenshots gemacht und daraus ein JPG gebastelt - vielleicht glaubt mir ja doch mal einer ;)


    [Blockierte Grafik: http://www.geocities.com/timo_brueggmann/winapebug.jpg]

  • Daß WinApe beim Speicher und dem Banking einen Bug hat, würde mich extremst wundern, da bei sowas elementarem jedes zweite Programm absemmeln müßte. SymbOS bankt rum wie irre, da kann eigentlich gar kein Fehler im WinApe sein.
    Du hast da nicht zufällig das Rom sichtbar gehabt oder zwischendurch eine #C1 oder #C3 Config angehabt, oder die Bildschirm-Ausgabe hat wegen Scrollings ausversehen ab #C000 was überschrieben?
    Am besten wäre ein kleines Beispiel-MC-Programm, das den Fehler nachproduziert (scheint ja ganz einfach zu sein, aber auf dem Screenshot sieht man ja den Code hinter und vor nicht "delentry". Sollte da wirklich ein Fehler sein, kann ich das dem Richard weiterleiten, der wird sich freuen (und ich wäre sehr sehr erstaunt ;) ).


    CU,
    Prodatron

  • Nein, ich hab nix mit dem Rom angestellt und die Bytes im ScreenRAM werden auch nicht überschrieben (leider sieht man sie auf dem CPC-Screen nicht). Die Codeteile sind recht simpel. Es sind einfache Schleifen, B der Zähler, HL der Zeiger und ein paar CPs. Auch lustig ist, das andere Debug-Werte (z. B. nach &9000) auch nicht vollständig ausgeführt werden. So führt die Sequenz


    LD A,255
    LD (&9000),A
    XOR A
    LD (&9001),A
    LD A,255
    LD (&9002),A


    auch nicht zum erwarteten &FF &00 &FF ab &9000 - sondern &9001 bleibt so, wie es vor Aufruf war. Ich glaube Dir, das es bei dir klappt - bei mir aber nicht. :(


    Was mich auch am Assembler nervt ist das verstümmeln von Text, wenn man Teile ausschneidet/kopiert und wo anders einfügen will. Dann sind die ersten 2-3 (oder mehr?) Zeilen erstmal zerstört. Desweiteren zerschießt selbst der aktuelle WinApe immernoch meine DSK-Files (schon wieder source-Files verloren :( ) Fehler habe ich schon weitergeleitet - seit ewigkeiten - aber nie antwort erhalten...


    Ich überlege mir ernsthaft, ein MaxAm-Eprom am CPC zu installieren - dann bin ich auf den "Affen" nicht mehr angewiesen....

  • Ich frag mich, wie um alles in der Welt Du das anstellst! 8) Hier mal genau Dein Beispiel:
    [Blockierte Grafik: http://www.symbos.de/files/temp/winape.gif]
    Fluppt natürlich wunderbar. Und Du scheinst ja auch die neuste Version zu haben. Was hast Du nochmal für einen PC?


    Wegen dem Editor: Den nutze ich natürlich auch nicht. Ich hab da nur so art Make-Files drin, die die richtigen Asm-Sourcen dann nachladen. Die Asm-Files selber editier ich mit Ultraedit.


    CU,
    Prodatron

  • Ich weiss auch nicht, wie ich das anstelle :shock: Ich hab aber alles überprüft und die Bytes werden im ganzen Programm nicht überschrieben. In den besagten Programmteilen wird auch E nicht überschrieben (das dachte ich ja zuerst). Ich vermute mal, der WinApe kommt bei mir nicht zurecht, wenn man ihn nicht nach jeder Änderung beendet und neu startet? Weil: Komisch war auch, das die erste Version am affen ohne Probleme lief, am echten CPC nicht, und nach neustart des PCs am WinApe auch nicht mehr :roll: Ich hab einen P3 500 MHz mit 256 MB RAM. Eigentlich zickt an der Kiste nur dieser Emu rum - alle anderen laufen.


    Ich sags ja - bei mir geht immer alle schief...

  • Prüf das dochmal im Debugger nach. Du setzt im Disassembler (mit F8 öffnen) einen Breakpointer vor der Stelle im Code, an der ins Ram geschrieben wird. Dann startest du das Programm, und das Ding hält bei dem Breakpoint an. Nun scrolls Du unten im Memory-Dump an die Stelle, die überschrieben werden soll und steps Dich mit F8 Schritt für Schritt weiter, beobachtest dabei, was im Disassembler für Befehle ausgeführt werden und was unten in der Memory-Anzeige passiert. Damit kannst Du das Problem recht schnell und einfach identifizieren.


    CU,
    Prodatron

  • Das werd ich mal testen - danke. Sag mal, ist es normal, das, wenn ich im Assembler-Fenster in den grauen Rand links klicke, und der Breakpoint gesetzt wird, WinApe aber trotzdem drüber läuft, ohne anzuhalten ("Enable Breakpoints" ist aber im Debugger gesetzt) ? Ich werd aber auf jeden Fall mal deine Vorgehensweise probieren. Thx.

  • Hm, weiß gar nicht, was im Assembler-Fenster solche Markierungen bedeuten. Eventuell mußt man die da dann noch mit einem Befehl extra einschalten.
    Jedenfalls setze ich die Breakpoints immer im Disassembler, und da funktionieren die bestimmt (hoffentlich auch bei Dir! :D ).
    Da bin ich ja mal gespannt auf Dein Ergebnis :shock:

  • Nur so nebenbei -falls eure Versuche, Winamp zu verwenden, doch fehlschlagen sollten...
    Ich benutze, wenn ich mal was bastel, immer Pasmo (http://www.arrakis.es/~ninsesabe/pasmo/). Ist ein ganz netter Kommandozeilenassembler, dazu noch Opensource und entsprechend fuer alle moeglichen Plattformen zu gebrauchen.
    Vorteil: Ich bin an keinen Emulator gebunden. Nutzung von Build-Tools, wie z.B. Ant (ich hab hier z.B. mal erst Resourcen komprimieren lassen, die dann beim Kompilieren eingebunden wurden).
    Nachteil: Kann evtl. von der Maxam Syntax etwas abweichen.

  • Der WinApe Assembler ist auch an keinen Emulator gebunden! :P


    Vorteile:
    - Maxam kompatibel
    - kann direkt in den Emu-CPC Speicher assemblieren (+ automatisch ausführen -> schneller und komfortabler gehts eigentlich nicht), aber auch genauso gut in Files auf der PC-Festplatte
    - kein Commandozeilen-Gerödel, statt dessen kann man die Projekte, mit denen man arbeitet, alle schön komfortabel in den Tabs offen haben und je nach Wunsch auf Klick/F-Tastendruck assemblieren
    - der interne Editor ist nur für "Make"-Files da, die Sourcen kann man daher super mit einem externen Editor bearbeiten
    - assembliert man für den CPC, so hat man im Emu direkt alle Labels verfügbar, sowohl in einer eigenen Liste, als auch direkt im Disassembler sichtbar - super zum Debuggen!
    - da man den Assembler sowohl perfekt für den CPC, also auch für jede andere Plattform gebrauchen kann, hat man keine Probleme mit unterschiedlichen Syntaxen für unterschiedliche Assembler usw.
    - die neueste Version hat nun auch eine sehr geile Makro-Sprache, mit der man nun quasi wirklich alles generische machen kann.
    - der WinApe-Author Richard Wilson ist seit Ende 2004 wieder schön aktiv und bringt einen Knüller nach dem anderen (das geilste in letzter Zeit ist das neue SNR Recording Format), daher ist Support und Weiterentwicklung momentan wohl gesichert.


    Ich kann gerne in 1,5 Wochen auf der XzentriX nochmal zeigen, wie man mit dem WinApe richtig schön für den CPC und andere Plattformen assembliert usw :) Es gibt weiterhin auf keinem anderen 8bit System einen Emulator mit einer derart guten Entwicklungsumgebung. Das ist mit WinApe auf dem CPC (leider? :P ) einmalig (ich wünschte, daß es auf mindestens 3 anderen Kisten genauso wäre).


    CU,
    Prodatron

  • Ich wollte jetzt hier absichtlich keinen Vergleich anstreben, da der interne Debugger von WinApe, in den der Assembler halt integriert ist, natuerlich von unschaetzbaren Wert ist, aber wenn Brueggi mit Pasmo besser klarkommt und Richard die Probleme nicht nachvollziehen kann, dann geht's evtl. mit Pasmo, der in Spanien uebrigens sehr beliebt ist.


    Bei WinApe ist es halt so, dass der neben Closed Source auch noch ein reiner Windows Emu ist. Unter Linux hab ich den bisher nicht gescheit einsetzen koennen und Mac Nutzer schauen auch in die Roehre. Auch wenn du eine Kommandozeile nicht so magst bin ich froh, wenn ich diverse Buildskripte laufen lassen kann. So kann man mit einem Kommando dann z.B. die Binaerdatei, eine Datei mit AMSDOS Header, die DSK Datei und ein CDT Image erzeugen, alles ZIPpen und evtl. Vorbereitungen fuer Bilddaten, Sourcedateien, etc. durchfuehren lassen. Alles etwas, was ich beim Programmieren zu schaetzen gelernt habe. Halt alles mit einem Befehl, wenn das Buildfile erstmal steht. Ob die Syntax jetzt genau Maxam kompatibel ist, ist mir persoenlich egal :-).
    Sogar MS hat das ja eingesehen und liefert mit MSBuild das entsprechende Kommandozeilentool fuer die .NET Umgebung, obwohl man das ja auch alles schoen aus Visual Studio heraus starten kann.
    Evtl. kann man ja bei Richard einen Featurerequest starten und der baut einen simplen Kommandozeilenparameter ein und schon ist das ausgebuegelt.


    Btw, Pasmo ist bspw. vollstaendig in TommyGun integriert. Da hat man dann eine komplette Entwicklungsumgebung fuer unterschiedliche 8-bit Rechner und mit einem Klick, wird das Projekt kompiliert und die kompilierte Datei dann auch automatisch in einem Emulator gestartet. Ein Editor mit Syntaxhighlighting und automatischer Datengenerierung aus den Sprites ist selbstredend auch mit dabei. Z88dk wird von TommyGun uebrigens auch direkt unterstuetzt :-).


    So, aber genug dazu - ich freu mich schon auf die XzentriX, da lass ich mir das dann mal von dir zeigen (vielleicht schwenke ich dann ja doch wieder um :-)).

  • Aber das mit der Kommandozeile hatte ich doch nur wegen Dir geschrieben, weil Du letztens nach nem DSK-Management-Tool ohne Kommandozeile gefragt hattest. Da dachte ich halt, sowas wär jetzt angesagt :D (hihi)


    Aber Du hast recht:
    - offiziell nur für Windows verfügbar
    - Für den MSX muß ich nach Starten des Winape-Assemblers noch ein Batch starten, das mittels Kommandozeilen-Tool noch das DSK erzeugt/beschreibt.
    - für den PCW muß ich nach dem Assemblieren noch im ManageDSK herumklicken - beides also nicht so das wahre.
    - Für den CPC muß ich aber gar nichts machen, nichtmal den emulierten CPC neu starten, da ich die assemblierte Applikation direkt von Festplatte reloaden kann. Und wenn ich halt ein normales CPC-Programm assemblieren will, wird das auf Knopfdruck direkt erzeugt + gleichzeitig direkt gestartet - ich hab dann mit den DSK gar nichts am hut, also besser gehts kaum.


    Also das TommyGun mußt Du mir dann echt nochmal genau zeigen!


    CU,
    Prodatron

  • Hm, TommyGun ist doch auch ausschließluch für Windows verfügbar, oder sehe ich das falsch?


    Ich hab letztens mal mit zmac und ein paar weiteren Tools & Buildscripten eine kleine Entwicklungsumgebung zusammengebastelt, die auch unter Linux (und wahrscheinlich auch Mac OS - hab ich noch nicht getestet) läuft. zmac soll bis auf ein paar kleine Ausnahmen MAXAM-kompatibel sein, bisher hab ich damit aber nur ein bisschen rumgespielt, also muss ich mal sehen, ob sich das bewährt.


    Pasmo hab ich bisher noch nicht gesehen, vielleicht muss ich mir das auch mal anschauen. Vielleicht kann ich mir ja von euch nächste Woche noch ein paar Anregungen holen...

    Nilquader of SPRING

  • Jupp TommyGun ist auch nur eine Windows Applikation, hat bei mir aber in Notfaellen auch unter Linux mit Wine funktioniert.
    Zmac hab ich auch schon verwendet. Der ist natuerlich auch nicht schlecht!


    @Prodi: Wuerde ich glatt auf der XzentriX machen, allerdings hat sich Anfang des Monats mein Notebook verabschiedet und obwohl ich mein neues noch am selben Tag bestellt bei einem Hersteller in Irland bestellt habe soll es fruehestens hier am 10.09. eintreffen *grummel*.

  • Zitat von &quot;almasys&quot;

    Oh, in der c't gab es, glaube ich, noch ein Projekt, den CPC6128 intern auf 512 KB aufzurüsten.


    Flopp und weg,
    AMSi


    Die aus der c't (gab es entweder als 512er oder 320er Erweiterung, je nach RAM-Bestückung) habe ich in meinen alten CPC 6128 damals eingebaut und die Software in mühevoller Kleinarbeit eingetippt und dann assembliert. Man hatte dann unter CP/M eine schöne große resetfeste RAM-Disk. Lief sogar, wenn ich mich recht erinnere, mit meinem Vortex F1-X-Laufwerk.


    Da habe ich auch gelernt, Umbauanleitungen erst zu lesen und dann umzusetzen - habe erst die falsche RAM-Bank mit Seitenschneider 'rausgeknipst und nach dem vermeintlichen Speicherupgrade lief er dann nicht mehr. Nachdem die Panik und der Ohnmachtsanfall vorbei waren, ging's dann an die (erfolgreiche) Fehlersuche.



    Andreas

  • Hat sich eigentlich noch jemand außer mir damals dir c't-Speichererweiterung zusammengelötet? Irgendwo auf dem Dachboden (gleicher Entropiefaktor wie Cygnus X-1) sollte ich noch die beiden Zeitschriften mit der Beschreibung haben. Bei Interesse schaue ich mal, ob ich sie wiederfinde, kann aber etwas dauern, sind ca. 30 Umzugskartons.


    Gruß,


    Andreas