Macht's doch nach $cf00. Dann ist der Kass.puffer frei und ab $c000 auch noch 3,75k.
Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 128 Antworten
letzter Beitrag von Bodhi1969 am
-
-
Hatte ich tatsächlich am Anfang schon überlegt. Der Datasettenpuffer schien mir trotzdem sinnvoller, weil der einfach sehr selten benutzt wird (außer eben für die Datasette)
Ich denke ne Abschaltung ist die bessere Lösung, mal schauen.
-
Hallo,
mus mal eine Zwischenfrage stellen.
Bitte mich nicht falsch verstehen....
We nutzt das dann ?
Oder wer es will... Oder gibt es noch andere Tools, die das gleiche machen, wie eures, bzw. dieses ?
Ich gehe mal davon aus das daß einTool ist das auf einem C64 leuft, oder ?
Sorry ich habe jetzt nich alles gelesen, in diesen Faden.
Wie arbeitet euer Tool ?
Wen ich ein BASIC Listing abtippen will ?
Vielleicht so:
Irgend einer hat ein tolles BASIC Listing verfasst (wir gehen mal ohne Fehler aus).
Jagd es durch euer Program, müssen ja irgenwelche "Checksummen"., sonst was entstehen, um dem, der es abtippt, eine Hilfestellung zu geben, ob er es richtig gemacht hat....
Sorry, ist eigentlich alles off topic, von mir, steht fast alles im eingangs Faden, zu diesen Tool.
Brotscheibe
-
Öhm ... nur für den Fall, dass das wirklich aus dem Threadanfang nicht ganz klar wird:
Die Verwendung des Checksummers an sich ist im ersten Posting beschrieben. Anwendungsfall ist wirklich nur um ein gedrucktes BASIC Listing abzutippen. Den Checksummer gibt's für VIC-20, C64, C16/116/+4 und C128.
Andere derartige Tools gibt es, zum Beispiel hatte die 64er ihren eigenen Checksummer, der aber deutlich anders funktioniert (und leider etwas "schwächere" Checksummen hatte, in späteren Versionen besser).
Um die Checksummen aus einem Programm zu erzeugen wird hier ein Tool für den PC verwendet, das passiert also nicht auf der originalen Maschine.
Alle Fragen beantwortet?
-
Willkommen zurück. Schön, dass Du wieder da bist.
Ich denke ne Abschaltung ist die bessere Lösung, mal schauen.
Eine Abschaltung hilft, falls man (erfolgreich) speichern will. Beim späteren Weitertippen hat man aber weiterhin Probleme, denn ein Laden von Kassette würde ja auch den ausgeschalteten Summer zerstören.
[Ausschalten kann man den Summer auch mit vier(?) Pokes, wenn man weiß, welche Werte wohin müssen]
-
Eine Abschaltung hilft, falls man (erfolgreich) speichern will. Beim späteren Weitertippen hat man aber weiterhin Probleme, denn ein Laden von Kassette würde ja auch den ausgeschalteten Summer zerstören.
Da hast du völlig recht, den Anwendungsfall, ein teilweise abgetipptes Programm weiter zu bearbeiten habe ich nicht bedacht.
Es gäbe vielleicht noch die Alternative, den Checksummer "unter" das ROM zu legen und irgendwo, wo es nicht stört, zwei kleine Umschaltroutinen zu haben -- das wäre aber eine Lösung nur für den C64 und würde da natürlich auch den Checksummer größer machen.
[Ausschalten kann man den Summer auch mit vier(?) Pokes, wenn man weiß, welche Werte wohin müssen]
Auch damit hast du völlig recht, muss allerdings in einer BASIC Zeile stehen. Abschalten auf dem C64 sollte so tun:
-
Ich habe mir jetzt einmal die Version 2.0 auf Linux kompiliert. Das Kompilieren klappte 1a.
Nur habe ich jetzt das Dilemma, dass, wenn ich den VIC-Checker lade, das vic20.prg aus dem Stammverzeichnis, mit einer Größe von 865 Byte, einen Syntax Error hervorruft, das f64summer.prg aus dem Unterverzeichnis VIC20 aber ohne Probleme geladen werden kann. Dies hat aber bei mir nur eine Größe von 183 Byte.
Welches ist das Richtige?
Die Varianten der anderen Rechner laden übrigens auch ohne Probleme - auf den jeweiligen Rechnern.
-
Naja, "Richtig" sind sowohl f64summer.prg, also auch vic20.bas als auch vic20.prg.
f64summer.prg ist ein (also das) Programm in Maschinensprache. Es wird (beim VC20) nach 820 geladen und läßt sich dann mit SYS 820 starten. Dieses Programm wurde aus der Assemblersource erstellt.
Da sich das in dieser Form schlecht in ausgedruckter Form (z.B in einem Weihnachtsheft) weitergeben läßt, wird daraus ein Basic Programm (ein Basic Loader) generiert. Den Quelltext kann einer ausdrucken, ein anderer abtippen und wenn der das Programm startet, "poked" es das Maschinenprogramm in den Speicher. Der Quelltext befindet sich in vic20.bas und kann mit einem Texteditor betrachtet werden.
Eigentlich wäre das alles, was man für dieses Projekt braucht. Tippt man vic20.bas ab und speichert es (z.B. auf Diskette) so erhält man vic20.prg, ein ladbares Basic Programm. Diesen Schritt hat Zirias uns auch noch abgenommen und erzeugt das vic20.prg aus vic20.bas mit Hilfe von petcat.
Für einen Heftersteller ist also vic20.bas wichtig. Für einen (faulen) Heftabtipper, der ein .prg in seine Hardware (oder Emulator) bekommt, sind die .prg von Nutzen.
Wenn vic20.prg nach dem Laden einen Syntax Fehler hat, ist entweder vic20.bas fehlerhaft erzeugt worden oder petcat hat nicht so funktioniert wie erwartet und hat aus einem korrekten vic20.bas ein kaputtes vic20.prg gemacht.
Ich habe kein Problem mit vic20.prg nach einem einfachen Aufruf von make. Sieht vic20.bas denn gut aus.? Hat das schon Syntax Fehler? Kannst Du das Listing von vic20.prg sehen? Ist hier ein Syntaxfehler zu erkennen?
-
