Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 99 Antworten

letzter Beitrag von markusC64 am

S-JiffyDOS für VICE

    Zitat von taschen244

    Zu kaufen, für einen einmaligen Test im Emulator?
    :abgelehnt


    Was willst du damit im VICE testen?
    Stell den Turbo auf z.B. 1000% oder so und dann hast du auch alles schneller geladen.
    Einen Vergleich der Speeder-Geschwindigkeiten findet man u.a. hier.

    Ja die Seite hab ich schon gesehen, das sind wohl Faktor Angaben die die da zeigen?
    Außerdem wollte ich mit Jiffy Dos ein paar Copy´s testen.
    1000% ist ja da wohl fürn Arsch :(


    Gibts denn da diese ROMs für den C64 und die 1541/71 auch mit Prologic / Professional / Dolphin Dos / Turbo Trans??
    Das wäre ja der nächste Schritt gewesen.
    Da würden mich dann die Filecopy bzw. Backup Zeiten interessieren und wie es mit dem schreiben und lesen bis Track 40/41 möglich ist.
    :drunk:

    Zitat von taschen244

    Gibts denn da diese ROMs für den C64 und die 1541/71 auch mit Prologic / Professional / Dolphin Dos / Turbo Trans??
    Das wäre ja der nächste Schritt gewesen.
    Da würden mich dann die Filecopy bzw. Backup Zeiten interessieren und wie es mit dem schreiben und lesen bis Track 40/41 möglich ist.

    Die von dir genannten Speeder sind nicht einfach Kernaländerungen (mit Parallelkabel), sondern haben zusätzliche Hardware im Diskettenlaufwerk. Ohne diese Hardware (oder einer teils möglichen Nachbildung mit The universal 6502 RAM/ROM Expansion) wirst du diese Speeder also nicht zum laufen kriegen.

    Im März 2013 hatte ich mich gewundert wie bei S-JiffyDOS-1541 das Byte $ec9b von $4c (JMP) nach $00 (BRK) gekippt war. Damals hatte ich alle defekten SJD-Versionen mit gekipptem Byte von meiner HD gelöscht. Jetzt habe ich mit dem Action-Replay unter VICE V2.1 das Floppy-DOS ausgelesen und es war wieder das gleiche Byte gekippt. Zuerst dachte ich, dass ich doch vergessen hatte ein defektes DOS-File zu löschen, aber dann habe ich herausgefunden, dass das 1541-DOS-File korrekt ist und dass VICE das korrekte Byte $4c bei $ec9b als $00 anzeigt. Es ist nur bei der alten V2.1, nicht mehr bei V2.4.
    VICE V2.1 überschreibt die Prüfsummenroutine beim 1541-Reset mit vier NOPs, sodass keine Prüfsumme über das DOS berechnet wird und ändert das Ende der Haupwarteschleife von JMP $EBFF zu BRK. VICE V2.1 scheint dieses BRK aus irgend einem Grund zu brauchen. Wenn man jetzt aber dieses DOS von der 1541 zum C64 mit dem M-R-Befehl ausliest (um beispielsweise bei einem DOS-PRG-File die Ladeadresse zu entfernen, damit man ein DOS-BIN-File erhält), dann werden diese fünf Bytes auch falsch ausgelesen und das erzeugte DOS hat fünf gekippte Bytes, sodass es abstürzt. Das fehlerhafte 1541-S-JiffyDOS-File war vermutlich nicht durch ein fehlerhaftes Patch-Programm erzeugt, sondern vermutlich eher von der Eigenart von VICE V2.1 Bytes im DOS zu ändern.
    Der Grund, warum ich immer noch VICE V2.1 benutze ist, dass ich häufig etwas ausdrucke (Einstellungen -> Peripherie Einstellungen -> Drucker 4 -> IEC Gerät aktivieren, Dateisystem, ASCII, Text, 1, c:\_VICE\viceprnt.txt).
    V2.1 macht ein Zeilenende mit $0d $0a, sodass Windows dies korrekt erkennt.
    V2.4 macht ein Zeilenende mit $0a $0d, sodass man den Text unter Windows schlecht weiterverarbeiten kann (siehe Anhänge).

    Zitat von NLQ

    Der Grund, warum ich immer noch VICE V2.1 benutze ist, dass ich häufig etwas ausdrucke (Einstellungen -> Peripherie Einstellungen -> Drucker 4 -> IEC Gerät aktivieren, Dateisystem, ASCII, Text, 1, c:\_VICE\viceprnt.txt).
    V2.1 macht ein Zeilenende mit $0d $0a, sodass Windows dies korrekt erkennt.
    V2.4 macht ein Zeilenende mit $0a $0d, sodass man den Text unter Windows schlecht weiterverarbeiten kann (siehe Anhänge).


    Dass ist wirklich etwas doof, wer denkt sich sowas aus? Die üblichen Zeilenumbrüche sind {CR}{LF} (ANSI/Windows1252) oder {LF} *nix/Linux/MacOSX.
    Das {LF}{CR} habe ich jetzt noch nie gesehen. Ist das die CBM Syntax?


    Da ich viel mit Schnittstellen Dateien zu tun habe: Wieso verwendest Du nicht Notepad++ unter Windows? Da kann man ruck-zuck mit CTRL+H das umwandeln mit Suche nach \n\r und Ersetzen nach \r\n, wenn man die Extended Option einschaltet.


    Das kann man auch als Makro abspeichern und schnell ausführen, wenn man es häufig benötigt. Ausserdem kann man im Notepad++ auch Sprachdateien hinterlegen für das Syntax-Highlighting. Wenn Du also viel solchen 6502 Assembler Output hast, einfach das Output File z.B. als "viceprnt.asm" definieren und die *.ASM Filetypen im Notepad++ mit der 6502 Syntax Sprachdatei hinterlegen - und Bob is your uncle.


    Habe das mal als Screenshot zusammengestellt und die unsichtbaren Zeichen eingeblendet, damit das besser sichtbar ist.
    Mit dem Notepad.exe arbeitet ich nicht mal auf Kundensystemen mehr.... ^^



    <Edit> Ich sehe gerade hier, dass Commodore nur das {CR} für einen Zeilenumbruch verwendet. Das wäre auch besser als das jetzige {LF}{CR} gewesen, das hätte man viel einfacher konvertieren können. Da muss jemand wohl ziemlich einen in der Birne voll mit Klosteinbräu gehabt haben, als er die beiden Bytes vertauschte.... :bgdev

    Zitat von Mac Bacon

    Zitat aus der Shoutbox:

    +1


    Also wenn das auf die {LF}{CR} Problematik gemeint ist: Ich hätte eine Erklärung/Einwand von den Erleuchteten erwartet, warum ich Nonsense schreibe und genau so wie es ist richtig ist, weil..... :bgdev


    Ist aber schon seit einem Jahr rapportiert als Bug.

    Zitat von Mac Bacon

    [Heute, 14:11] schumi: wirre workarounds zu 5 jahre alter software diskutieren statt offensichtliche bugs zu melden :thumbsup:


    Wirre Einstellung. Heute noch mit 30 Jahre alter Hardware rumzumachen, die immer noch voller Fehler steckt. :gahh:
    Wenn du nur aktuelle Sachen willst, geh bitte in ein PC/Apple-Forum. :böse

    Zitat von Shoutbox

    [Heute, 14:11] schumi: wirre workarounds zu 5 jahre alter software diskutieren statt offensichtliche bugs zu melden :thumbsup:


    Zitat von syshack

    Ist aber schon seit einem Jahr rapportiert als Bug.


    Erstellt am 11. Mai 2013, Rückfrage am 25. Jan 2014, seitdem nichts mehr.
    NLQ: Bau einen Testcase für die Rückfrage, und bald ist der Bug Geschichte.

    Zitat von c64doc

    Wirre Einstellung. Heute noch mit 30 Jahre alter Hardware rumzumachen, die immer noch voller Fehler steckt. :gahh:
    Wenn du nur aktuelle Sachen willst, geh bitte in ein PC/Apple-Forum. :böse

    Lass Dir von Deinem Zoff mit sauhund nicht den Blick trüben - hier ging es weder um Hardwarefehler, noch um "aktuelle Sachen": NLQ hat explizit gesagt, eine veraltete VICE-Version zu benutzen, nur weil die aktuelle Version einen Bug hat; und das Fixen des Bugs wäre nun mal deutlich weniger Aufwand als der beschriebene Workaround.
    Hätte NLQ stattdessen gesagt, dass er Spaß an der Herausforderung mit dem alten VICE hat, ja dann...

    NLQ: Bekommst Du immer nur {LR}{CR}? Wie bei meinem Screenshot weiter oben ersichtlich ist, hatte es bei mir teilweise {LR}{CR} dann vereinzelt aber auch nur {CR}.
    Allerdings habe ich nur schnell ein kleines BASIC Testlisting mit folgenden Befehlen ausgedruckt:

    Code
    1. OPEN 1,4
    2. CMD 1
    3. LIST
    4. CLOSE 1


    Zwischen den BASIC Zeilen hat es nur {CR}, aber auch z.B. vor dem READY.
    Mir fällt auch auf, dass das Outputfile leer erstellt wird, und erst nach dem Beenden des VICE die Buffer ins File geschrieben werden, also nicht nach dem CLOSE 1.
    Scheint aber auch ein bekanntes/gewolltes Problem zu sein.

    Zitat

    Bekommst Du immer nur {LR}{CR}? Wie bei meinem Screenshot weiter oben ersichtlich ist, hatte es bei mir teilweise {LR}{CR} dann vereinzelt aber auch nur {CR}.

    Ich habe mal geschaut, was der reale C64 sendet (auf einen MPS1230 im Hex-Dump-Mode. Er sendet:

    Code
    1. (24) (60) 0d 0d 0a 52 45 41 44 59 2e 0d 0a 0d ...
    2. CR CR LF r e a d y . CR LF CR

    Der C64 sendet bereits manchmal LFs bei CMD und LIST.


    Zitat

    Mir fällt auch auf, dass das Outputfile leer erstellt wird, und erst nach dem Beenden des VICE die Buffer ins File geschrieben werden, also nicht nach dem CLOSE 1.

    Das Outputfile wird erstellt, sobald ein CLOSE zum Drucker gesendet wird. Bei OPEN1,4 und CLOSE wird kein CLOSE gesendet; bei OPEN1,4,0 (!mit Angabe der Sekundäradresse!) wird ein CLOSE gesendet.
    open1,4:print#1,"abc":close1:rem vice erzeugt outputfile erst beim schliessen von vice
    open1,4,0:print#1,"abc":close1:rem vice erzeugt outputfile sofort


    So klappt es mit dem PRINT#-Befehl zwischen OPEN und CLOSE. Der CMD-Befehl hat aber noch eine Eigenart (, die ich bisher auch nicht kannte).
    open1,4,0:cmd1:print"abc":close1:rem vice erzeugt outputfile erst beim schliessen von vice
    open1,4,0:cmd1:list:close1:rem vice erzeugt outputfile erst beim schliessen von vice
    Obwohl beim Öffnen die Sekundäradresse angegeben wird, wird kein CLOSE zum Drucker gesendet. In "Alles über den Commodore 64" steht auf Seite 39/40: "Damit die Ausgabe wieder auf dem Bildschirm angezeigt wird, muß (1984) der Befehl PRINT# eine Leerzeile vom CMD-Gerät vor dem Schließen (CLOSE) schicken, damit dieses nicht mehr auf die Datenübertragung wartet (dies nennt man "Unlistening" des Geräts)."
    D.h. man braucht noch ein PRINT#:
    open1,4,0:cmd1:print"abc":print#1:close1:rem vice erzeugt outputfile sofort
    open1,4,0:cmd1:list <return>
    print#1:close1:rem vice erzeugt outputfile sofort
    OPEN, CMD und LIST muss in einer eigenen Basiczeile stehen; PRINT# und CLOSE in einer anderen, sonst klappt's aus irgendwelchen unerklärlichen Gründen nicht.


    Wenn man am C64 ein File erzeugen will, das nicht nur CR am Zeilenende sondern CR+LF hat, so geht das, wenn man eine logische Filenummer zwischen 128 und 255 benutzt:
    open1,4,0:print#1,"aa":print#1,"bb":close1:rem zeilenende = cr
    open128,4,0:print#128,"aa":print#128,"bb":close128:rem zeilenende = cr+lf
    Beim Action-Replay bringt mir dies allerdings nichts.

    Danke für den Tipp bzgl. OPEN mit SA. Dass das auf VICE Auswirkungen hat bzw. das "echte" CLOSE verhindert, wenn die fehlt, war mir nicht bewußt. Dass es Unterschiede gibt, ob mit oder ohne SA geöffnet wird, hatte ich allerdings auch schon erlebt, als ich mit OPEN4,GA,SA mal eine Gibt-es-den-Drucker-Abfrage gebastelt hatte. Das geht regelmäßig schief und bricht mit "deviece not present" ab. Macht man das mit OPEN4,GA (also ohne SA) kann man (ohne Fehlermeldung) am Status-Flag ablesen, ob der Drucker existiert oder nicht. Die Lösung für mein Problem: eine SA=255 ist wie keine SA (kann man beim Studium des Kernals heruasfinden).


    Zitat von NLQ

    OPEN, CMD und LIST muss in einer eigenen Basiczeile stehen; PRINT# und CLOSE in einer anderen, sonst klappt's aus irgendwelchen unerklärlichen Gründen nicht.

    Wieso sollte das ein "unerfindlicher Grund" sein? Nach LIST kehrt der Interpreter immer zum READY zurück. Dahinterliegender Code wird also ignoriert. Das war schon beim PET so und ist auch beim C128 so. Der Gedanke dahinter ist halt, dass ein LIST aus dem laufenden Programm heraus keinen Sinn ergibt (wir wissen es natürlich besser).

    Zitat

    Danke für den Tipp bzgl. OPEN mit SA. ... Dass es Unterschiede gibt, ob mit oder ohne SA geöffnet wird, hatte ich allerdings auch schon erlebt, als ich mit OPEN4,GA,SA mal eine Gibt-es-den-Drucker-Abfrage gebastelt hatte. Das geht regelmäßig schief und bricht mit "deviece not present" ab. Macht man das mit OPEN4,GA (also ohne SA) kann man (ohne Fehlermeldung) am Status-Flag ablesen, ob der Drucker existiert oder nicht. Die Lösung für mein Problem: eine SA=255 ist wie keine SA (kann man beim Studium des Kernals herausfinden).

    Es freut mich, dass es dir etwas gebracht hat. Um das Vorhandensein eines seriellen Gerätes abzufragen mache ich:
    open15,GA,15:close15:?st
    Falls ST = 0, dann gibt es das Gerät, ansonsten nicht.


    Zitat

    Wieso sollte das ein "unerfindlicher Grund" sein? Nach LIST kehrt der Interpreter immer zum READY zurück. Dahinterliegender Code wird also ignoriert.

    Stimmt, du hast recht. Ich hab mir nochmals die Basic-Interpreter-Routine angesehen.

    Zitat

    Bau einen Testcase für die Rückfrage, und bald ist der Bug Geschichte.

    Am 28.12. habe ich die Eigenart genauer erklärt und ein Tag später war eine Anpassung da; vielen Dank. Es klappt wunderbar. Ich hab's mal genauer angesehen mit: open1,4:cmd1:list:close1 und dem File mit dem Inhalt "1 rem":

    Code
    1. C64: 0d 0d 0a ready. 0d 0a 0d | 0d 0d 0a
    2. VICE V2.1: 0d 0a 0d 0a 0a ready. 0d 0a 0a 0d 0a | 0d 0a 0d 0a 0a
    3. VICE V2.4.0: 0a 0d 0a 0d 0d ready. 0a 0d 0d 0a 0d | 0a 0d 0a 0d 0d
    4. VICE V2.4.12: 0d 0a 0d 0a 0d ready. 0d 0a 0d 0d 0a | 0d 0a 0d 0a 0d
    5. (R28919)

    Der C64 macht ein Zeilenende meist mit $0d = CR = CarriageReturn. Seltener macht er dies mit $0d+$0a = CR+LF = CarriageReturn+Linefeed. Ein seltenes C64-Zeilenende (0d 0a , CR LF) wird zu einem 3-Byte-Windows-Zeilenede (0d 0a 0d , CR LF CR), was aber absolut in Ordnung ist. Ein normales C64-Zeilenende (0d , CR) wird absolut korrekt zum Windows-Zeilenende (0d 0a , CR LF) gewandelt.
    VICE ist ein absolut toller Emulator; vielen Dank an alle Programmierer. Gerade zum Patchen des Kernals oder des DOSs ist es eine enorme Erleichterung eine neue Version einfach in VICE anklicken zu können, anstatt jedes mal ein EPROM brennen zu müssen. Für den absoluten Spezialfall, das Anfahren von Track 0,5 bei der Lichtschranken-1541c, musste ich beispielsweise drei EPROMs brennen bis die Routine lief.

    Habe das Thema wegen einem anderen Thread wieder gesucht.
    Danke für die Info. Dein letztes Posting ist irgendwie an der Neujahrsfeier an mir vorbeigegangen. :thumbup:

    Zitat von NLQ

    Ich lege in die LW8 1541-II das 32kB DOS sjd_rom_c1541.bin ein. Nach einem Reset lese ich den Fehlerkanal aus und erhalte: 73,s-jiffydos 1 1541. Nun lege ich das 16kB DOS jd6.01_rom_c1541_fixed.bin ein. Nach einem Datei -> Reset -> hart ist LW8 nicht mehr ansprechbar.
    Erst nach Beenden und Neustarten von VICE zeigt LW8 an: 73,jiffydos 5.0 1541
    Zum Umschalten zwischen 16kB- und 32kB-DOS sollte man meiner Meinung nach VICE neu starten, aber du hast Recht, die ROM-Images werden sofort geladen.

    Bin gestern und heute über das selbe Problem gesolpert - und dabei die Beobachtung gemacht: Macht man nach der Auswahl des 16k ROMs eine zweimalige Typenänderung des Laufwerkes (also z. B: von 1541-II nach 1571 und zurück, geht es ohne Neustart.


    Da ist wohl noch ein Fehler im Vice.