80 x 50 Pixel im Textmodus malen

Es gibt 51 Antworten in diesem Thema, welches 17.534 mal aufgerufen wurde. Der letzte Beitrag (2. Januar 2021 um 15:35) ist von Ratte.

  • detlef: Ich meine mich an ein solchen Programm erinnern zu können, kann aber nirgendwo etwas finden. Hast Du Deine Version noch irgendwo?

    Ich muss mal suchen. Von den Assembler-Sachen aus meiner PET 2001-Zeit ist leider nicht alles erhalten, weil ich damals noch auf Kassette gespeichert und nicht alles auf Floppy umkopiert habe. Leider.

    Auf dem CBM hatte ich dann irgendeine Basic-Erweiterung, die das von hause aus konnte.

    EDIT: Ich hab da was gefunden. Leider komplett ohne Doku und die Sourcen existierten ja nur auf Papier. Ich werde das mal disassemblieren und schauen, wie es funktionierte. Vermutlich je ein POKE für X- und Y- Koordinate und je ein SYS für Setzen und Löschen des Punktes.

    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von detlef (3. Oktober 2020 um 09:05)

  • 80 x 50 Pixel:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Hier hab ich noch mal eine gekürzte Poke-Version.
    Man kann das Problem also in circa 4-5 Zeilen und mit einem Feld lösen.

    Für jene, die das überhaupt ausprobieren wollen, wäre es den Forumsteilnehmern nett gegebenüber, solche Programme in einem Code-Abschnitt (Copy und Paste geht auch aus einem VICE-Screen) oder in einem txt-Anhang textuell anzugeben. ;)

  • Ist doch in 2 Minuten abgetippt: (sogar mit den Doppelpunkten, deren Sinn ich immer noch nicht begreife, ist aber der Stil von BIF )

    Code
    10 :rem--80x50 pixel-demo
    11 :dimi,v,h,b,x,y,a(255):h=1:v=peek(648)*256::print"er“80 x 50:"
    12 :fori=.to15:readb:a(b)=i:a(i)=b:next
    13 :b=62:data32,126,124,226,123,97,255,236,108,127,225,251,98,252,254,160
    14 :y=11:forx=.to79:gosub16:next
    15 :x=21:fory=.to49:gosub16:next:end
    16 :i=v+x/2+20*(yandb):pokei,a(a(peek(i))or(h+(xandh))*(h+3*(yandh))):return
  • ... sogar mit den Doppelpunkten, deren Sinn ich immer noch nicht begreife, ...

    Im C64-BASIC beschleunigt jeder Doppelpunkt in einer Zeile die interne Bearbeitungsgeschwindigkeit.

    Man muss allerdings bei der Benutzung dieser undokumentierten Funktion vorsichtig sein. Bei zu vielen Doppelpunkten droht der CPU der Hitzetod, da sie zu sehr beschleunigt wird. Um diese wieder etwas abzubremsen, sollte man gelegentlich einen Strichpunkt in die BASIC-Zeilen mit einbauen.

    Langjährige Erfahrung zahlreicher C64-Nutzer hat gezeigt, dass ein ideales Gleichgewicht zwischen Beschleunigung und Abbremsen in etwa bei 3 Doppelpunkten, gefolgt von einem Strichpunkt pro BASIC-Zeile liegt. :alt:

    Also in etwa so: 10 :N = U / R - E : IN = S * P - A + S - S :  ;-) 

  • Tatsächlich kann man die : sehr gut zum minimalen abbremsen einsetzen, ist einfacher als z.b. mit einer fornextschleife zu bauen.

    Wobei es relativ selten vorkommt dass man BASIC auch noch einbremsen muss! :D

  • der . macht aber tatsächlich einiges aus wenn man mal wieder in einer Basic Beschleunigungs Challange gelandet ist! :wink:
    Da gabs jja schon einiges, wie z.B. Lottozahlen oder Sortierroutinen ...

  • Lustiges Thema.

    Auf dem C128 kommt man bis zu 160 x 100 (mit speziellem Zeichensatz) : Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Ich habe mein GOTO-Monster debugged.

    Als Datei im Anhang.

    Ich hab da so eine Idee .... bald sind Herbstferien in NRW.

    :D

  • Ist doch in 2 Minuten abgetippt: (sogar mit den Doppelpunkten, deren Sinn ich immer noch nicht begreife, ist aber der Stil von BIF )

    Ja eh, es geht ums Prinzip.

    Das sind da 2 Minuten bei *allen*, die es Abtippen und in Summe dann ein Zeitaufwand, der uns allen quasi aufgezwungen wird. Es war ja auch nur eine Bitte, doch den Lesern entgegenkommender zu sein, speziell wenn man eine Lösung der Leserschaft schmackhaft machen möchte und damit den Zugang dazu möglichst einfach zu gestalten.

  • Immer mit der Ruhe. Er hat es sicher nur vergessen, da er es doch sonst immer macht. Und wenn das Interesse wirklich so groß ist, ist es schneller abgetippt, als sich hier noch so lange darüber. Schließlich kannst Du es jetzt doch ohne die umständliche Abtipperei von mir runterladen. ;)

  • Die Laufzeit (fürs Kreuzzeichnen) reduziert sich von 5,27 s auf 4,63 s, das sind 12 % Ersparnis. Immerhin. Es ist gerade so viel, dass man "merkt", dass es schneller ist, wenn auch nicht bahnbrechend.

    Es geht noch schneller:

    Ich hab ja ´ne Schwäche für 80x50, wenn "eigene" Zeichen im Dot-Matrix-Look genutzt werden

    Für die Grafik, auf die dein Link verweist, kann man aber nicht den Zeichensatz aus dem ROM verwenden.

    Dafür muß man einen eigenen Zeichensatz definieren:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Gruß,

    Neptun

  • Es geht noch schneller:

    Stimmt, mit der Tabelle für die Zeilenanfänge. Kam noch nicht dazu "nachzulegen". Wunderbar, passt! :)

    Apropos Nachlegen: Man kann noch x/2 als Tabelle realisieren. Ein früh definiertes Array sollte auch noch flotter sein, als eine FP-Division. ;)

  • Schönes Thema!

    Für mich wäre es schön und besser nachzuvollziehen, wenn in ein paar REM Zeilen angegeben wäre was

    da gerade passiert. Unabhängig jetzt vom Thema Speed! Nur so, wegen dem lernen! :)

  • Ja, lesbarer Basic-Code scheint wirklich aus der Mode gekommen zu sein. Jedes Stück Beispielcode ist hochoptimiert, 80 Zeichen in einer Zeile, . statt 0 usw.

    Und läuft dann auch nur auf dem Interpreter, für den er optimiert wurde.

    Das bezieht sich jetzt gar nicht auf den Beispielcode hier Thread. Hier ging es ja tatsächlich um den schnellsten Code. Ich meine mehr so im Allgemeinen.

  • Ich muss halt auch jeden einzelnen Poke im Plan nachsehen um mir zusammen zureimen was da grade passiert

    und das ist sehr mühsam.
    Gerade für diesen Code wären ein paar REM Erklärungen sehr interessant und lehrreich. :whistling:

    Gruß,

    Neptun

  • Beim Sharp MZ-80A ist das auch die einzige Möglichkeit etwas Grafik zu haben. Dort ist das bereits in Basic integriert. Allerdings kann ich jetzt nicht sagen, in welcher Version von Basic das integriert ist, da beim MZ-80 Basic erst mal von Kassette geladen werden muss.

    Bitte melde dich an, um dieses Bild zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Hallo, ich denke mal, daß mein Prg trotzt Doppelpunkten das kürzeste ist.

    Oder täusche ich mich?

    Also von Doppelbelastung kann wohl keine Rede sein.

    Schönen Gruß.

  • Also hier noch mal das Prg als 4-Zeiler.
    Damit hätte man dann wohl die kürzeste Abtipp-Zeit, die kürzeste Speicherzeit und die kürzeste Ladezeit. Und die Arbeits-Geschwindigkeit ist auch nicht schlecht.
    Dazu kommt natürlich noch die gute Lesbarkeit, wegen der Doppelpunkte.

    0 :rem--80x50 pixel-demo

    1 :dima(255):print"[clr]80 x 50:":fori=.to15:readb:a(b)=i:a(i)=b:next

    2 :data32,126,124,226,123,97,255,236,108,127,225,251,98,252,254,160

    3 :y=11:forx=.to79:gosub4:next::x=21:fory=.to49:gosub4:next:end

    4 :i=1024+x/2+20*(yand62):pokei,a(a(peek(i))or(1+(xand1))*(1+3*(yand1))):return

    Schönen Gruß.

  • Es geht (hier) weder ums Eintippen, noch um die Programmkürze. Der Doppelpunkt am Zeilenanfang ist schlicht sinnlos, es sei denn, man möchte per Einrückungen mit Leerzeichen die Struktur im Progamm hervorheben. Davon kann man aber in der hier präsentierten Spaghettischreibweise wohl nicht ausgehen. ;)