in SEQ schreiben (auf device #9)

  • Nur so generell zum Schreiben von sequentiellen Dateien. Weil hier nur genau ein Ziechen geschrieben wird, sollte man sich beim Auslesen vielleicht nicht wundern. Ich hab es bislang zumindest in BASIC nachvollziehen können, aber möglicherweise (ich würde es erwarten) ist das aus aus MC heraus auch so, dass bei Schreiben von weniger als 2 Zeichen, 4 Zeichen in der Datei stehen ... siehe C64-Wiki
  • @paradroid:

    äh ja :-), aber nein :)

    ich hatte eure post verfolgt und kontrolliert:
    zu der zeit war bei mir das von euch berichtete in meinem code noch richtig,
    aber irgendwie gab es immer irgendweclhe fehler rund um das label mit den "filename"-text
    - entweder es wurde nicht richtig angelegt (oder sowas) und <fname + >fname war gleich *=$codestart)
    oder ich legte die label nach hinten und ich bekam "phase error" (label benutzt vor deklaration)

    also hab ich die ganzen label und die macros damit entfernt und alles neu (ohne label) eingegeben
    - dieses mal allerdings mit screencodes statt petscii-codes :)

    so kam dann eins zum anderen :)
    allemallachen
  • JeeK schrieb:

    Nur so generell zum Schreiben von sequentiellen Dateien. Weil hier nur genau ein Z[ei]chen geschrieben wird, sollte man sich beim Auslesen vielleicht nicht wundern. Ich hab es bislang zumindest in BASIC nachvollziehen können, aber möglicherweise (ich würde es erwarten) ist das aus aus MC heraus auch so, dass bei Schreiben von weniger als 2 Zeichen, 4 Zeichen in der Datei stehen ...
    Hups!? Ich wollte das zuerst nicht glauben, und hab' das darum mit einem eigenen Testprogramm in VICE mit TDE ein nachgestellt, zuerst mit einer 1541, dann noch mit der 1581.

    Daß CBM DOS leere Dateien nicht kennt, wußte ich ja schon, aber daß es sich auch bei 1-Byte-Dateien vertüddelt, nicht.

    Ein typisches DOS-Problem, aber mit der 1581 hätte man das ja schon beheben können. Leider tritt der Fehler auch da auf. :(
    Dateien
    • testbench.zip

      (1,73 kB, 3 mal heruntergeladen, zuletzt: )
  • e2020 schrieb:

    ... ich konnte an der letzten version zwar sehen, dass es die labels waren, die zu falschen ergebnissen führten, konnte es aber nicht repaieren - manchmal denke ich ich bin NICHT die einzige mögliche fehlerquelle die einfluss auf meinen code hat obwohl ich alleine vor dem rechner sitze...

    so, also alles (zurück auf) so einfach wie möglich:

    Quellcode

    1. ; ausgabe in seq auf disk# 9
    2. *= $1000 ; sys 4096
    3. lda #14 ; "n"
    4. sta $03c0 ;
    5. lda #1 ; "a"
    6. sta $03c1
    7. lda #13 ; "m"
    8. sta $03c2 ;
    9. lda #5 ; "e"
    10. sta $03c3 ;
    11. lda #44 ; ","
    12. sta $03c4 ;
    13. lda #19 ; "s"
    14. sta $03c5 ;
    15. lda #5 ; "e"
    16. sta $03c6 ;
    17. lda #17 ; "q"
    18. sta $03c7 ;
    19. lda #44 ; ","
    20. sta $03c8 ;
    21. lda #23 ; "w"
    22. sta $03c9 ;
    23. ;==================1v3 open SEQ
    24. ;basic: open 2,9,4,"1,seq,w"
    25. lda #2 ; #15
    26. ldx #9 ; #8
    27. ldy #4 ; #15
    28. jsr $ffba ;Parameter setzen
    29. save2file
    30. lda #$0a
    31. ldx #$c0 ;>fname2
    32. ldy #$03 ;<fname2
    33. jsr $ffbd
    34. jsr $ffc0 ;"Open" file offnen
    35. ;====================2v3 print#
    36. ;basic: print #2, "text"
    37. ldx #2 ;LOGISCHE FILENUMMER
    38. jsr $ffc9 ;"chkout" ausgabe
    39. ; auf file !
    40. lda #73 ; " i "
    41. jsr $ffd2 ;print
    42. jsr $ffcc ;"clrch" CLEARchannel
    43. close ;=====================3v3 close
    44. lda #$02 ; filenumber 2
    45. jsr $ffc3 ; call CLOSE
    46. rts ;========= zurueck zu BASIC
    Alles anzeigen
    und: funktioniert NICHT

    hä?
    Was passiert denn, wenn Du anstelle der Anführungszeichen ein einfaches Hochkomme nimmst? Also Zeilen 5 und folgende anstelle von " das ' nimmst...

    DoReCo #55 am Sa. 16.12.2017 :dafuer: