Beiträge von strik

    In COMAL kann man Programme nicht nur mit SAVE in tokenisierter Form auf Diskette speichern - was eine PRG-Datei ergibt. Nein, COMAL erlaubt es auch, mit dem Befehl LIST das komplette Programm (oder nur bestimmte Teile) als reine Textdatei auf Diskette zu speichern. Dabei entsteht keine PRG-Datei, sondern eine SEQ-Datei - also eine echte Klartext-Datei!


    Man kann beim LIST-Befehl sogar genau angeben, was man speichern möchte:

    Zeilennummern: LIST 100-350
    Prozedurnamen: LIST meineprozedur

    Kannst du in BASIC aber auch machen:

    Code
    OPEN 1,8,2,"DATEINAME,S,W"
    CMD 1
    LIST 100-350
    PRINT#1
    CLOSE 1

    Solche SEQ-Dateien lädt man später nicht mit LOAD, sondern mit ENTER in den Speicher. Sie lassen sich auch mit MERGE an bestehende Programme anhängen - entweder am Ende oder sogar mittendrin!

    Nur das geht mit "Boardmitteln" bei BASIC nicht ganz so einfach, ist aber mit einem kleinen Hilfs-Programm auch nicht unmöglich

    Ob das klappt hängt auch von der Version der C64-Platine und den verrwendeten Speicher-Chips(*) in Rechner und REU ab. Das stärkere Netzteil war ja einfach nur eins, das bei Commodore schon im Regal lag. Der echte Mehrbedarf waren wahrscheinlich nur 100-200 mA in der ungünstigsten Kombination.

    Mein C64 war ein im Dezember 1983 gekaufter C64. Kein CMOS, 8 RAM-Chips, Original ROMs. Ich glaube nicht, dass das eine besonders stromsparende Variante war.

    Ich habe eine 1750, die noch mehr Leistung braucht, mit einem Original C64-Netzteil betrieben, weil ich es nicht besser wusste. Es ging also grundsätzlich.

    Das würde ich zwar heute nicht mehr empfohlen, wenn ein kurzer Test aber sagt, dass gar nichts geht, würde ich eher von einer defekten 1764 ausgehen.

    Was heisst aber: "Tut gar nichts"? Womit hast du das getestet? Die REU hat keinen "konventionellen" Speicher; ohne spezielle Programme weiß der C64 also gar nicht, dass sie angeschlossen ist. Das wirkt dann erst einmal so, als ob sie gar nichts tut.

    Erst einmal: GUI4cbm4win war nie Teil von OpenCBM und wird es auch nicht werden

    Spricht etwas gegen dieses CBM4WinGUI ? Zu alt ? Wird nicht mehr supported ?

    Wenn ich die Internetquellen richtig deute ist die letzte Version 18 (!) Jahre alt und benötigt die VB6 Runtimes ... ob das überhaupt noch funktioniert entzieht sich meiner Kenntnis :D

    GUI4cbm4win wird tatsächlich nicht mehr direkt weitergepflegt. Muss es auch nicht, weil CbmXFer darauf basiert:

    History

    CBM-Transfer (aka "CBMXfer") is based on GUI4CBM4WIN (G4C from now on) by Leif Bloomquist, Wolfgang Moser, and Spiro Trikaliotis. G4C 0.4.1 source code was used as a starting point for CBM-Transfer. Most of the G4C code has been heavily modified or rewritten. The viewer also contains portions of code from CBM2BMP 1.1 by Peter Weighill.

    Wer also die GUI braucht, nimmt am besten CBM-Xfer oder eine der anderen genannten Lösungen.

    Habs gefunden. Zadig hieß das Tool. Jetzt wird der Atmega auch richtig erkannt und ich konnte die Firmware "xum1541-ZOOMFLOPPY-v08.hex" auf den Atmega flashen.


    Ich habe opencbm nun installiert und anschließend CBM4Win installiert. Soweit sieht nun alles gut aus, getestet wird dann morgen.

    Hättest du es anders herum gemacht, wie ich Bitte melde dich an, um diesen Link zu sehen. empfohlen habe, hättest du ZADIG gar nicht nutzen müssen. Bei der Installation von OpenCBM wird nämlich der Treiber für den DFU-Modus quasi mitinstalliert:

    Problem ist häufig, dass unter Windows der Treiber nicht installiert ist. Da hilft es, OpenCBM zu installieren und den Treiber installieren zu lassen.

    Ansonsten auch mit ZADIG, das sollte aber eigentlich unnötig sein.

    dafür ist meine Anleitung universeller und nicht nur auf den xum1541 beschränkt und man lernt auch paar generelle Sachen. Egal, viele Wege führen nach ROM und ich mache es weiterhin so und nicht anders :smile:

    Na klar darfst du das weiterhin so machen.

    Du kannst dann allerdings auch froh sein, dass der Ansatz, der ZF über xum1541cfg eine Identifikation zu geben, nie umgesetzt wurde. Das würde nämlich mit dem DFU-Programmer nicht klappen, weil er davon nichts gewusst hätte. Das hätte Folge-Probleme hervorbringen können.

    Ich wundere mich allerdings, wieso man jemandem, der offenbar Windows nutzt, zuerst den Tipp gibt, Linux zu nutzen? Ich würde zwar auch Linux bevorzugen, versuche mich aber dem Fragesteller anzupassen und nicht dem Fragesteller meine Arbeitsweise aufzudrängen.

    Zumal der DFU-Programmer ja auch unter Windows existiert.

    Laut der Aussage von Snocksman wird aber ein "xum1541" device erwartet, zumindest bei dem Update das er versucht hat aber das kann es doch ohne einen initialen Flash des ATMega garnicht geben, oder :gruebel ?

    Bitte die Ausgabe richtig lesen:

    Code
    finding and preparing device for update...
    warning: no xum1541 found, continuing to look for devices in DFU mode
    error: no devices found to update

    Zuerst sucht er nach einem XUM-Gerät. Was da nicht steht: Wenn er eins finden würde, dann würde er es in den DFU-Modus schalten.

    Weil er keins findet, gibt es aber die warning, das er keins gefunden hat. Die Warnung sagt aber, dass er jetzt ("trotzdem") noch nach Geräten im DFU-Modus sucht. Es kann ja sein, dass das xum keine gültige Firmware drauf hat (wie beim ersten Flashen).

    Da er auch dies nicht findet, gibt es dann den Fehler, dass er keine Geräte zum Updaten gefunden hat.

    Hier die Kommentierung von "ON" aus "64intern":

    Man sieht, dass er immer folgendermassen vorgeht: Es wird der "Zähler" (das "E" in deinem Beispiel) in $A957 dekrementiert. Ist es danach 0, dann wird der GOTO oder GOSUB-Befehl einfach ausgeführt. ($A95B-$A95C) (Dieses ON ist wohl auch der Grund, wieso GOTO und GOSUB nicht testen, ob nach der Zahl noch etwas kommt, weil sie hier fehlschlagen würden. Es ist also kein Fehler im BASIC, sondern Absicht, dass "GOTO 1000,.+-$" keine Fehlermeldung ausgibt.

    Ansonsten wird eine Zeilennummer gelesen ($A95F-$A962) und ignoriert und getestet, ob ein Komma folgt. Falls ja, wird erneut das E dekrementiert (s.o.)

    Falls nichts mehr folgt, wird die Routine einfach verlassen, das "ON ... GOTO/GOSUB" hat dann also gar keine Auswirkung.

    Durch die Dekrementierung vor dem Test erreicht man auch, das für E=0 auch nichts ausgeführt wird, weil das einem E=256 entspricht.

    Das habe ich übrigens in "Das Maschinensprache-Buch für den C64" von Lothar Englisch schonmal gesehen, im Einzelschritt-Simulator sogar noch interessanter:

    Code
    1110 ONAGOTO1200,1210,1220,1230,1240,1250,1260,1270,1280,1290,1300,1310,1320,1330
    1115 A=A-14
    1120 ONAGOTO1340,1340,1360,1370,1380,1390,1400,1410,1420,1430,1440,1450,1470,1470
    1125 A=A-14
    1130 ONAGOTO1480,1490,1500,1510,1520,1530,1540,1550,1560,1570,1580,1590,1600,1610
    1135 A=A-14
    1140 ONAGOTO1620,1630,1640,1650,1660,1670,1680,1690,1700,1710,1720,1730,1740,1750
    1150 GOTO200

    Er hätte hier ein berechnetes GOTO besser gebrauchen können:

    Code
    1110 IF A=0 OR A>42 GOTO 200
    1120 GOTO 1190+10*A
    Code
    16552 onegoto16553,16554,16550,16550,16550,16999:goto16551

    Was soll daran nicht funktionieren?

    Das ersetzt sinngemäß:

    Code
    if e = 1 goto 16553
    if e = 2 goto 16554
    if e = 3 goto 16550
    if e = 4 goto 16550
    if e = 5 goto 16550
    if e = 6 goto 16999
    goto 16551

    weil ich gern nach dem KISS-Prinzip arbeite - KeepItSimple,Stupid !

    Und so hab ich schon sackweise AVRs mit dfu-Bootloader programmiert und es funzt einfach - ohne "Gerätemanager" und anderen unnötigen Kram !

    Kann man sich auch in ein Script schreiben, dann gehts auch später noch ohne nachzudenken :wink:

    Der Gerätemanager (genauer: Die Notwendigkeit, einen passenden Treiber für den DFU-Modus zu haben) liegt an Windows und ist tatsächlich ein (kleineres) Problem, das man mit Linux umschiffen kann.

    Bloß habe ich mich nicht darauf bezogen, sondern auf den DFU-Programmer. Das auf die ZoomFloppy spezialisierte Tool, welches den DFU-Programmer sofort korrekt initialisiert und eben keine eigenen Einstellungen benötigt, würde ich eher als KISS bezeichnen. Man muss nicht selber den Chip detekten. Man muss nicht löschen, schreiben und dann resetten. Das alles macht xum1541 automatisch, während man mit dem DFU-Programmer mehr Möglichkeiten hat, etwas falsch zu machen.

    Heißt, ich kann einfach über den USB-Anschluss die Platine mit dem Rechner verbinden und sollte das Teil flashen können ? Dann schau ich mir die Batch-Datei gerade mal genauer an.

    Genau so sollte es funktionieren, ja.

    Problem ist häufig, dass unter Windows der Treiber nicht installiert ist. Da hilft es, OpenCBM zu installieren und den Treiber installieren zu lassen.

    Ansonsten auch mit ZADIG, das sollte aber eigentlich unnötig sein.

    Aber das hasst du ja inzwischen gelöst.

    Nun mache ich natürlich auch kein Update, sondern versuche einen jungfräulichen Atmega zu programmieren...

    Edit: Oder muss ich den Atmega erst über einen der Lötbrücken auf der Rückseite in den DFU-Mode bringen ?

    Das Tool sollte sowohl Update als auch Erst-Installation hinbekommen.

    Den DFU-Modus musst du nur aktivieren, wenn du schon eine FW geflasht hast. Das ist bei dir aber nicht der Fall.

    aber wenn ich das im PDF richtig deute funktioniert "firmware-update" nur, wenn der ATMega bereits einmal geflasht wurde und das Gerät im Windows Geräte Manager erkannt wird ;)

    Ersteres stimmt nicht, auch die Erst-Installation geht.

    Im Geräte-Manager muss es aber (als DFU-Gerät) erkannt werden.

    1) Gibt es eine Art Speicherbegrenzung für Printzeilen? Also ein Limit? Ich kann mich erinnern, früher habe ich teilweise Adventures mit 100 Blocks auf der Diskette geschrieben, die liefen problemlos, aber andere liefen schon bei 50 Blocks in irgendwelche OUT OF MEMORY Fehler. Das habe ich nie verstanden aber ich hatte damals auch niemanden, den ich fragen konnte. Mein Eindruck war, dass es eher mit zu vielen GOSUB Zeilen und -Verschachtelungen zu tun hatte.

    Die 100 Blöcke oder 50 Blöcke klingen mir nach dem, was du schreibst, nicht als der begrenzende Faktor.

    Für die GOSUBs hast du nur den Stack des 6502, der 256 byte groß ist. Jedes GOSUB verbraucht dabei 5 Byte davon. D.h., du kannst nicht beliebig schachteln.

    "Schlimm" wird es, wenn du das RETURN vergisst, sondern z.B. per GOTO rausspringst. Dann ist der Speicher "verloren" und kann nicht wiedergeholt werden.

    Darüber hinaus verbrauchen auch FOR-Schleifen Speicher auf dem Stack, sogar 7 Byte. Wenn du ohne NEXT eine Schleife beendest, dann ist auch dieser Speicher weg. Zum Glück kann man zumindest diesen Effekt mindern, wenn die FOR-Schleife innerhalb einer Subroutine steckt, die mit RETURN beendet wird: Das RETURN "bereinigt" nämlich alle FOR, die zwischendurch (also nach dem GOSUB) gelaufen sind. Ebenso wird bei geschachtelten FOR..NEXT-Schleifen eine innere FOR-SChleife geschlossen, wenn die äussere beendet wird (Beispiel: Bei "FOR I=1 TO 100:FOR J = 1 TO 50:NEXT I" wird die FOR J-Schleife bereinigt)

    Auch hier gibt es jedenfalls "OUT OF MEMORY"-Fehlermeldungen, die man erst einmal verstehen muss.

    Ich muss übrigens korrigieren:

    • GOSUB: braucht 7 Byte des Stacks
    • FOR: braucht 18 Byte des Stacks

    1) Gibt es eine Art Speicherbegrenzung für Printzeilen? Also ein Limit? Ich kann mich erinnern, früher habe ich teilweise Adventures mit 100 Blocks auf der Diskette geschrieben, die liefen problemlos, aber andere liefen schon bei 50 Blocks in irgendwelche OUT OF MEMORY Fehler. Das habe ich nie verstanden aber ich hatte damals auch niemanden, den ich fragen konnte. Mein Eindruck war, dass es eher mit zu vielen GOSUB Zeilen und -Verschachtelungen zu tun hatte.

    Die 100 Blöcke oder 50 Blöcke klingen mir nach dem, was du schreibst, nicht als der begrenzende Faktor.

    Für die GOSUBs hast du nur den Stack des 6502, der 256 byte groß ist. Jedes GOSUB verbraucht dabei 5 Byte davon. D.h., du kannst nicht beliebig schachteln.

    "Schlimm" wird es, wenn du das RETURN vergisst, sondern z.B. per GOTO rausspringst. Dann ist der Speicher "verloren" und kann nicht wiedergeholt werden.

    Darüber hinaus verbrauchen auch FOR-Schleifen Speicher auf dem Stack, sogar 7 Byte. Wenn du ohne NEXT eine Schleife beendest, dann ist auch dieser Speicher weg. Zum Glück kann man zumindest diesen Effekt mindern, wenn die FOR-Schleife innerhalb einer Subroutine steckt, die mit RETURN beendet wird: Das RETURN "bereinigt" nämlich alle FOR, die zwischendurch (also nach dem GOSUB) gelaufen sind. Ebenso wird bei geschachtelten FOR..NEXT-Schleifen eine innere FOR-SChleife geschlossen, wenn die äussere beendet wird (Beispiel: Bei "FOR I=1 TO 100:FOR J = 1 TO 50:NEXT I" wird die FOR J-Schleife bereinigt)

    Auch hier gibt es jedenfalls "OUT OF MEMORY"-Fehlermeldungen, die man erst einmal verstehen muss.

    Comal reicht halt den COPY-Befehl weiter an die Diskettenstation und führt selbst keinen Kopiercode aus. Das ist zumindest die sehr naheliegende Schlussfolgerung.

    Dabei hätte man das so toll mit Streaming machen können:

    OPEN der Datei auf dem Ziellaufwerk zum Schreiben, OPEN der Datei auf dem Quelllaufwerk zum Lesen, LISTEN zum Ziellaufwerk, TALK zum Quelllaufwerk, und ab geht's. Warten auf Beendigung, UNLISTEN/UNTALK auf die Laufwerke, CLOSE auf beide und fertig ist die Maus.

    Dauert auch nicht länger, als die Datei einzulesen, und benötigt gar nicht so viel Platz im C64 (außer der Logik zur Erkennung, ob es das gleiche Laufwerk oder ein anderes Laufwerk ist).

    AAAAaaaa wird als $01 $01 $01 $01 $41 $41 $41 $41 abgelegt. Das $41 macht (nach Bitte melde dich an, um diesen Link zu sehen.) Sinn aber auf $01 ist kein grosses A......

    Das sind offensichtlich Screen codes:

    Bitte melde dich an, um diesen Link zu sehen.