Aber wenn es das schon gibt, warum das Rad neu erfinden?
Einfach weil es jemanden vielleicht interessiert wie man sowas programmiert
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Aber wenn es das schon gibt, warum das Rad neu erfinden?
Einfach weil es jemanden vielleicht interessiert wie man sowas programmiert
Aber wenn es das schon gibt, warum das Rad neu erfinden?
Einfach weil es jemanden vielleicht interessiert wie man sowas programmiert
Leider finde ich diese geprinteten Daten sehr hässlich. Das ist was für 10-Zeilen-Wettbewerbe.
Aber wenn es jemand anderes programmieren möchte, würde ich es mir mal angucken.
Aber was macht denn ein Maskengenerator? Er wandelt die Bildschirmcodes in ASCII, damit es beim PRINT wieder genau zu den Bildschirmcodes wird. Also muss das auch mit Maschinenprogrammen funzen.
Ein Bildschirmmaskengenerator muss aber zum einen nicht den gesamten Zeichenvorrat ($00-$FF) beherrschen, zum anderen nicht größere Speicherbereiche.
Dann kann man sowas doch recht schnell mal einbauen…
Ich meine, ich hätte sowas schon mal angefragt, aber gerne wieder. Kannst Du sowas in C64Studio einbauen?
Leider finde ich diese geprinteten Daten sehr hässlich.
Ja, aber dafür ist es wesentlich schneller als das Gepoke mit DATA-Zeilen. Platzsparender dürfte es auch sein. Und im Endeffekt geht es ja um Effektivität.
Leider finde ich diese geprinteten Daten sehr hässlich.
Kannste mit Vordergrundfarbe = Hintergrundfarbe auf den Bildschirm schreiben, dann siehste nix
Man kann ja die Zieladresse von Print ändern, ohne dem vic zu sagen dass er die Daten von wo anders holen soll.
dann sieht man davon auch nix.
Ich hatte schon mit strings und chr$ gearbeitet, aber dann trotzdem wieder mit FOR und MID$ mühsam in den Speicher gepoked.
print ist ziemlich genial
Ich hatte schon mit strings und chr$ gearbeitet, aber dann trotzdem wieder mit FOR und MID$ mühsam in den Speicher gepoked.
In diesem TSB-Trick hole ich eine Bildschirmausgabe direkt in einen String. Das würde dir Stringmüll ersparen.
Arndt
Ein Maskengenerator übersetzt einen mühsam erstellten Textbildschirm in die passenden PRINT-Zeilen - aber doch kein Maschinenprogramm aus dem Speicher!
Das Maschinenprogramm muß sich natürlich im Bildschirmspeicher befinden, damit der Maskengenerator es sieht. Das kann man ggf. auch per Freezemodul-Monitor dort hin verschieben.
Was macht man denn mit opcodes, die man nicht schreiben kann? Cursor, Farben, Reverse, Home, clear?
Kannste mit Vordergrundfarbe = Hintergrundfarbe auf den Bildschirm schreiben, dann siehste nix
Oder man gibt gleich das Ziel per $0288 an. Siehe Ausgangspost.
Vorher noch den Bildschirm löschen, dann ist auch die Farbe egal.
Leider finde ich diese geprinteten Daten sehr hässlich.
Kannste mit Vordergrundfarbe = Hintergrundfarbe auf den Bildschirm schreiben, dann siehste nix
Ich meinte das Listing.
Ein Maskengenerator übersetzt einen mühsam erstellten Textbildschirm in die passenden PRINT-Zeilen - aber doch kein Maschinenprogramm aus dem Speicher!
Das Maschinenprogramm muß sich natürlich im Bildschirmspeicher befinden, damit der Maskengenerator es sieht. Das kann man ggf. auch per Freezemodul-Monitor dort hin verschieben
Ja, das meinte ich: Man braucht zumindest noch zusätzliche Software, um den Maskengenerator auf solche Weise zu zweckentfremden.
Gibt es dazu bereits ein Tool, was einem aus einem bestehenden Speicher die Print-Zeile generiert?
Das war doch hier im Forum schon mal Thema ...irgendwo ...vor Quartalen?
Daher: hab's auf meiner Platte gefunden, hier der Link:
Print Is the New Poke [2019] https://csdb.dk/release/?id=177079
Gibt es dazu bereits ein Tool, was einem aus einem bestehenden Speicher die Print-Zeile generiert?
Das war doch hier im Forum schon mal Thema ...irgendwo ...vor Quartalen?
Daher: hab's auf meiner Platte gefunden, hier der Link:
Print Is the New Poke [2019] https://csdb.dk/release/?id=177079
Danke, aber die Lösung ist nicht so toll, wie die aus dem Video, da sie die Zeilen ja nur anzeigt und nicht speichert. Das Tool aus dem Video speichert die Zeilen wenigstens auch. Bei längeren Speicherauszügen bekommt man da Probleme, da die Zeilen aus dem Bildschirm laufen. Ich weiß jetzt auch nicht genau was passiert, wenn es über größere Bereiche geht. Da muss ja der Bildschirmspeicher immer wieder verschoben werden, sonst erreicht man Adressen irgendwann nicht mehr.
... Ich weiß jetzt auch nicht genau was passiert, wenn es über größere Bereiche geht. Da muss ja der Bildschirmspeicher immer wieder verschoben werden, sonst erreicht man Adressen irgendwann nicht mehr.
Du kannst eh nur den Bereich von $0000 - $03e7 eines $0400 Blockes ansprechen.
Und wenn du so grosse Maschinenspracheblöcke nutzen willst, wieso dann nicht gleich reinladen?
Spart Basic-Speicher!
Danke, aber die Lösung ist nicht so toll, wie die aus dem Video, da sie die Zeilen ja nur anzeigt und nicht speichert.
Ja, stand so aber nicht in der Ausgangsfrage. (p.s. ...man muss halt manuell mit RETURN über die Zeilen gehen und dann manuell saven.)
Bequemer geht's immer, d.h. wäre endgeil, wenn es das C64 Studio könnte!
Dann kann man sowas doch recht schnell mal einbauen…
Endurion Hmm, heisst das ggf., du ziehst in Erwägung, eine "To PRINT" Funktion in den Binary Editor einzubauen?
Möglicherweise?
Hab mal am Binary-Editor rumgebastelt und die Option mit eingebaut.
Ich habe jetzt nur einen Datenblock mit allen Bytes von 0 bis 255 getestet, sah aber im Speicher sauber aus.
Neue WIP-Version dafür!
Ich habe jetzt nur einen Datenblock mit allen Bytes von 0 bis 255 getestet, sah aber im Speicher sauber aus.
Sieht auf den ersten Blick schon mal ganz gut aus. Was jetzt noch fehlt, sind die Pokes, damit es auch da landet, wo es soll. Dabei müsten natürlich auch Pagegrenzen berücksichtigt werden und beim Beginn, wenn der Block nicht an einer Pagegrenze beginnen soll, der Cursor entsprechend gesetzt werden. Außerdem braucht man dafür dann zwischendurch auch Pokes, wenn Pagegrenzen überschritten werden, damit das "Fenster" weiter rückt.
Als absolutes I-Tüpfelchen wäre dann noch, wenn die Pokes sogar noch für C16, C128 & Co generierbar wären.
Ich weiß, jetzt wird es anspruchsvoll. Aber es hat ja keiner gesagt, dass es einfach sein soll
Jetzt geht's aber los hier!
Jetzt geht's aber los hier!
Wenn schon, denn schon.
Ich kann auch gleich nen Bug berichten.
Wenn das letzte Zeichen ein Anführungszeichen ist, werden 2 Anführungszeichen geprintet, was dazu führen würde, dass die nächste Speicherstelle auch überschrieben wird, obwohl sie gar nicht angetastet werden sollte.
Na gut, da hast du
Optional gibt es ein Adressfeld. Mit $ oder 0x-prefix ist die Adresse hex, sonst dezimal. Das setzt dann ein POKE 648 passend ein, bei Werten nicht auf einer Page wird SPC(...) mitgenommen.
Zum Test hatte ich $c013 verwendet.
Das doppelte Anführungszeichen am Ende sollte auch Geschichte sein.
Jetzt geht's aber los hier!
Kleiner Finger....
...