Suche Bankswitching-Lösung

  • Hallo Leutz...
    Ich suche ein Bankswitching-Programm, welches schnell ist.
    Beispiel: Ich lade ein Bild in Adresse &4000, möchte es dann blitzschnell auf Adresse &C000 switchen...
    Und dieses am Besten noch bei 512K und so um die 8 Bilder...
    Weiss da jemand Rat?
    Programm kann gern Maschinencode enthalten und mit RSX-Befehlen ausgerüstet sein.
    Ich möchte es dann unter Basic nutzen können.


    Grüssle, Markus

  • Ich weiss, ich kenne den Bankmanager,
    aber gibt es vielleicht eine 'schnellere' Lösung?

  • Also schneller als so:


    <!-- m --><a class="postlink" href="http://www.youtube.com/watch?v=_9S8DvimBdo">http://www.youtube.com/watch?v=_9S8DvimBdo</a><!-- m -->


    ...geht es auch mit Ram-Copies nicht, weil LDIR genauso schnell wie OUTI:INC B ist. Mit LDI:LDI:LDI:LDI: würdest Du maximal 12 fps schaffen.


    CU,
    Prodatron

  • Hi Prodatron.
    Das würde vollkommen reichen.
    Leider liegt es auch schon etliche Jahre her, dass ich den Bankman benutzt habe...
    Wie waren dafür nochmal die Befehle? *dummguggs*

  • 25x gelesen, und niemand kann mir mehr sagen, wie die RSX-Befehle zum Bankmanager waren? :(

  • Danke für den Tipp!
    Das Handbuch habbsch ja ooch uff meinem Server...
    Glatt mal nachglotzen binnz

  • JA. Kapitel 8, Seite 1, habs auch schon gefunden.
    Irgendwie raff ich das zwar grad garnet aber egal... Werds mir morgen mal im CPC anschauen...
    Versuch macht klu(g)ch
    Ich finde nur den Bankman sehr langsam... Drum hätt ich gern für Basic ne schnellere Lösung gewusst.
    Kann man damit denn auch 512Kb Ram ansprechen?

  • auf der cpm-disk1 ist der bankmanager als basdatei und die dazugehörige bin-datei.
    ist super zu bedienen, die befehle stehen im handbuch dafür.


    ich habe noch eine pdf-seite, wie die bankdateien funktionieren.


    wie werden solche dateien eigentlich hier reingeladen?


    mfg

  • Wo der Bankmanager ist, weiss ich.
    Schick mir mal bitte das PDF als Email an cpc-live[at]devilmarkus.de
    Danke.
    Werd es dann auf meinen Server schieben und für Alle zugänglich machen.

  • Danke Dir für das PDF.


    Hier ist es für die Anderen zum Download:
    PDF-Datei
    Ich dachte eher an etwas, womit die Bankswitching Befehle wie |screenswap oder |screencopy bissl besser erklärt sind, für Dummies wie mich. Aber ich werds morgen mal austesten.
    So nun muss ich aber ins Bettchen!

  • ....Ich finde nur den Bankman sehr langsam......


    die bankman.bin ist schon ein asm-code.


    das es so langsam geht, liegt an den schlechten aufbau der grafik-byte im screen, da ist der c64 mit 1mhz viel schneller, weil da die bytezusammengehörigkeit durchdachter ist.


    gib mal beim cpc ein:


    10 for a=0 to 512
    20 poke &c000+a,255
    30 next a



    dann sieht du den aufbau. schlimmer wird es, wenn man noch eine linie proggen muss in diesem gewusele.


    mfg

  • Zitat

    das es so langsam geht, liegt an den schlechten aufbau der grafik-byte im screen, da ist der c64 mit 1mhz viel schneller, weil da die bytezusammengehörigkeit durchdachter ist.


    Bei allem Respekt, mach das selbe mal in Assembler. Da siehst Du den Aufbau fast gar nicht. Und eine Copy Routine von &4000 nach &c000 kann man so schnell machen, dass man die Einblendung fast gar nicht wahrnimmt.
    Und die Paar OUT's um die Bank umzuschalten, sind wohl auch nicht so schwierig zu meistern. Die Speichererweiterung kannst Du zur Not sogar in Basic umswitchen.


    Aber der C-64 ist wesentlich langsamer im Bildaufbau, da vergleichst Du auch Äpfel mit Birnen. Der VIC ist komplett anders organisiert, ausserdem bedenke mal die Auflösung die der CPC fährt!


    Ausserdem gefällt mir die Erklärung nicht gut. Was ist bitteschön ein "schlechter Aufbau der Grafikbytes im Screen?"
    Wodurch ist das definiert und woher nimmst das Wissen für diese Behauptung? Das ist ein allgemein gehaltener Satz, welcher mit ein Paar "Fachworten" ein Problem zu umschreiben versucht, welches kein Problem ist.


    Schreibe mir doch mal Deine Copyroutine in C-64 Code und in CPC Code auf. Mal sehen welche länger und welche komplizierter ist. :wink:


    Ich bin gespannt, was Du dabei herausbekommst. Nun ja, wollen wir es nicht ganz so spannend machen. Die C-64 Routine ist länger und komplizierter.
    Eigentlich ist der Bildschirmspeicher des CPC wesentlich einfacher und unkomplizierter zu handlen, als der olle VIC. Im Prinzip weiß ich was Du aussagen möchtest. Du meinst den zeilenweisen Aufbau. Den kannst Du aber ändern, zum Beispiel von unten nach oben oder umgekehrt. Ist nur ein wenig umändern der Rechenroutine. Versuche mal einen zeilenweisen Aufbau mit dem VIC. :shock:


    Also alles in allem ist die Aussage des "schlechten Aufbau's" eine pauschale, persönliche Meinung von Dir und kein Problem des CPC. Man muss den Aufbau des CPC natürlich auch verstehen und das verstandene korrekt umsetzen können. Ansonsten macht man schnell mal eine unbedachte Äusserung, der Aufbau ist nämlich gar nicht schlecht. Er ist sogar hocheffizient und sehr schnell!


    So Du brauchst eigentlich nur eine Copyroutine und ein Paar Outs zum Umschalten der Bank. Das war es auch schon....


    Gruß
    Pentagon

  • Zitat von &quot;super_castle&quot;


    gib mal beim cpc ein:


    10 for a=0 to 512
    20 poke &c000+a,255
    30 next a


    Danke für diesen Tipp!
    Aber mir wäre hilfreicher gewesen, wenn jemand mal ein Beispiel für den Bankman geschrieben hätte.
    Dass ab &C000 bzw 49152 der Bildschirminhalt liegt, weiss ich ja, und auch dass er &4000 bzw 16384 Bytes beträgt.
    In Basic geht eh alles bissl langsamer, aber damit muss ich ja leben.
    Ich habe vor, eine kleinere 'Slideshow' zu machen, welche als 512k Snapshot gespeichert werden kann.
    Deshalb auch die Fragerei von mir.


    Grüssle, Markus

  • Ich denk mal, super_castle meint die komischen Lineoffsets beim CPC (#c000, #c800, #d000, ... #c050, #c850 usw.) sowie die seltsame Codierung der Pixel innerhalb eines Bytes in Mode 1 und Mode 0. Diese Umstände verlangsamen das simple Kopieren eines 16K Screens natürlich nicht. Sie bereiten einem aber ein bischen Kopfzerbrechen, wenn es dann halt z.B. um das schnelle Zeichnen einer Linie geht.


    Was Devilmarkus sucht, kann z.B. so aussehen:



    Diese Routine kopiert alle 32 Screens aus dem 512KB Erweiterungsram. Sie schafft 10fps, braucht also für die 32 Screens 3 Sekunden.
    Schneller geht es noch, wenn man LDIR mit LDI:LDI:LDI:LDI:LDI:... usw ersetzt.


    CU,
    Prodatron

  • Hallo Prodatron,
    ja genau das ist eigentlich was ich suche.
    But please in BASIC!!! Von Assembler habe ich soviel Ahnung, wie eine Schildkröte vom Weitsprung...
    Wäre klasse, wenn Du mir so ein Prog. auf DSK schicken könntest mit einer kleinen Erklärung, wie man davon in Basic gebrauch machen kann.
    LG Markus

  • Hmmpf, du warst 5 Minuten schneller als ich :)


    Ich sitze gerade noch dran, wollte es erst ausprobieren. Aber genauso habe ich es gemeint :)


    Und jetzt mach das gleiche mit der REU und dem VIC am 64er :twisted:
    Mal sehen wieviel Zeilen Code dabei rauskommen.


    Zitat

    Sie bereiten einem aber ein bischen Kopfzerbrechen...


    Genau das gleiche habe ich ja mit anderen Worten geschrieben. Aber das ist kein "schlechter Aufbau", sondern ein Verständnisproblem.


    Gruß
    Pentagon

  • Ich könnte mir das ganze z.B. so vorstellen:


    CALL &A000,1 > Kopiert Bildschirminhalt in Bank 1
    CALL &A000,2 > Kopiert Bildschirminhalt in Bank 2
    ....
    CALL &A000,8 > Kopiert Bildschirminhalt in Bank 8


    CALL &A400,1 > Spielt Bank 1 auf Bildschirm zurück
    CALL &A400,2 > Spielt Bank 2 auf Bildschirm zurück
    usw usw...
    Gibt s da eine Lösung für?

  • Zitat von &quot;Pentagon&quot;

    Und jetzt mach das gleiche mit der REU und dem VIC am 64er :twisted:
    Mal sehen wieviel Zeilen Code dabei rauskommen.


    Au ja, das würd mich echt mal interessieren!! :)


    Zitat


    Genau das gleiche habe ich ja mit anderen Worten geschrieben. Aber das ist kein "schlechter Aufbau", sondern ein Verständnisproblem.


    Ja, das liegt wohl z.B. daran, daß der CRTC ursprünglich für Textmodes gedacht war, daher diese komischen Lineoffsets.


    CU,
    Prodatron

  • Zitat von &quot;Devilmarkus&quot;

    Hallo Prodatron,
    ja genau das ist eigentlich was ich suche.
    But please in BASIC!!! Von Assembler habe ich soviel Ahnung, wie eine Schildkröte vom Weitsprung...
    Wäre klasse, wenn Du mir so ein Prog. auf DSK schicken könntest mit einer kleinen Erklärung, wie man davon in Basic gebrauch machen kann.
    LG Markus


    Du kannst das einfach so machen:
    - WinApe nehmen und ins Basic gehen
    - dort mit F6 den Assembler öffnen
    - den Code dort hineinpasten
    - CTRL+F9 im Assembler drücken oder Assemble -> Assemble klicken
    - wieder ins Emu-Fenster gehen
    - CALL &a000 machen


    Das war's.
    Das MC-Programm kannst Du mit
    save"scrcopy",b,&a000,&23
    auf ein DSK speichern und später in einem Basic-Programm mit
    memory &9fff:load"scrcopy"
    wieder laden.


    CU,
    Prodatron

  • Zitat von &quot;Devilmarkus&quot;

    Ich könnte mir das ganze z.B. so vorstellen:


    Hm, aber genau das kann doch alles der Bankman.
    Ist der denn so lahm? Der wird auch nur mit LDIRs arbeiten, nehm ich mal an...


    CU,
    Prodatron

  • Übrigens wird ein "Video" nicht so gut aussehen, wenn man auf die obige Weise die Screens nacheinander kopiert. Grund ist vor allen Dingen der vorhin angesprochene "seltsame" Lineoffset. Du wirst einen Art 8fachen Interlace-Effekt bemerken, was der Abspiel-Qualität ziemlich schadet.


    Besser wäre es, wenn man folgendes macht:
    - Man switcht zwischen zwei Screens bei #8000 und #C000
    - Während man den Screen bei #8000 anzeigt, kopiert man den nächsten nach #C000
    - Nun zeigt man diesen an und kopiert den nächsten nach #8000
    - und wieder von vorn


    Damit hat man die optimalste Abspielqualität, das wird dann so aussehen wie in dem YouTube-Video, was ich hier gepostet hatte.
    Das kann man aber nicht in Basic machen, weil man dabei den gesamten Betriebssystem-Bereich ab #Axxx überschreibt.


    Eine andere nicht ganz optimale Lösung wäre noch die folgende:
    - man legt die Screens wie große Sprites ab und kopiert sie zeilenweise auf den Bildschirm, das ist geringfügig langsamer, sieht aber wesentlich besser aus als mit dem 8fachen Interlace-Effect.


    CU,
    Prodatron

  • Danke Dir Prodatron,
    nun könnte ich noch eine kleine Beschreibung gebrauchen, wie ich die einzelnen Bilder auf die verschiedenen Bänke ablegen kann.
    Die lade ich ja schliesslich auch noch...
    Z.B. LOAD"SCREEN1.SCR",&C000
    Wie bekomm ich nu dies Bild auf eine Bank?
    Und wie hole ich es wieder heraus auf den Bildschirm?

  • Ich habe nicht vor, einen Film zu machen, aber eine kleine Slideshow, welche ich als Snapshot speichern kann.

  • Zitat von &quot;Devilmarkus&quot;


    Z.B. LOAD"SCREEN1.SCR",&C000
    Wie bekomm ich nu dies Bild auf eine Bank?


    Dazu würde ich wie gesagt den Bankman nehmen


    CU,
    Prodatron

  • Ja klar, aber irgendwie kapiere ich die Befehle vom Bankman nicht so wirklich.
    Kannst Du sie nem Dummen nochmal erklären anhand eines kleinen Beispiels?
    Danke Dir schonmal im Vorraus.

  • Da fällt mir gerade ein, der unterstützt ja nur die zweiten 64K, also maximal 4 Screens. Nee, dann kann man den doch nicht nehmen.



    Versuchs mal damit.
    Die Subroutine ab 100 poket den MC-Code rein,
    400 kopiert aus den 512K einen Screen in den Bildschirm
    500 macht das umgekehrte


    CU,
    Prodatron

  • Ach ja, und bitte nicht abtippen, sondern die Paste-Funktion vom WinApe nehmen ;)


    Dein Hauptprogramm würde dann z.B. so aussehen:


    10 gosub 100
    15 rem ### LADEN ###
    20 load"screen0",&c000:screen=0:gosub 500
    30 load"screen1",&c000:screen=1:gosub 500
    40 load"screen2",&c000:screen=2:gosub 500
    45 rem ### ABSPIELEN ###
    50 screen=0:gosub 400
    60 screen=1:gosub 400
    70 screen=2:gosub 400
    80 end


    CU,
    Prodatron

  • Zitat


    Ausserdem gefällt mir die Erklärung nicht gut. Was ist bitteschön ein "schlechter Aufbau der Grafikbytes im Screen?" ...


    damit meine ich , beim aufbau werden resourcen verschenkt.


    der cpc baut die nächste linie immer 8 zeilen im abstand auf , erst wenn der screen voll ist kommt genau die 2. nachfolgende linie, hat man dem fernsehbild abgeschaut, ist so ähnlich wie ein halbbild, dem auge wird ein ruhigerer bildaufbau vorgetäuscht, was auch klappt. der c64 hat die klötzchen-grafik, immer 8 byte genau untereinander und dann kommt das nächste klötzchen was rechts daneben liegt. der vorteil ist das die liniengrafik weniger asm-code braucht auf grund des günstigeren aufbaues.



    ps: die reu lässt sich wunderbar proggen mit asm beim c64 im vice, ist ähnlich der cpc-bank-routinen. man kann schöne grafikbilder als film ablaufen lassen, zb die drehende erdkugel aus der reu mit ein darum herumfliegendes spriteraumschiff.
    das geosram läst sich genauso leicht proggen im vice, bloss da muss man die ganze copiererei von hand erledigen, das heisst eine eigene routine schreiben, ist aber wieder eine schöne herausforderung für uns tüftler.


    aber beim z80 gibt es doch auch noch die schnellen kopierbefehle :
    LDD, LDDR, LDI, LDIR


    mfg