Posts by SvOlli

    Du kannst das ROM aber auch in einer aktuellen Version des "Stalla"-Emulators spielen. Der unterstuetzt die meisten Sachen, die auf dem NXP umgesetzt wurden. Er ist schließlich das Werkzeug, mit dem (auch) diese Spiele debugged werden. VCS Urgestein David Crane hat darauf hingewiesen, dass er ebenfalls die Debug-Funktionen auch viel nutzt. Allerdings auch nicht genug, sonst wären weniger Fehler in "Circus Convoy" gewesen...


    (Danke an Retrofan, dessen Erklärung so exakt war, dass ich dem nichts mehr hinzufügen muss. ;) )


    Wobei ich auch nicht gerade ein Fan von diesen "Coprozessor"-Sachen bin, denn wie schon im zweiten Post in diesem Thread kommt dann sofort die Frage auf: "warum hat man das nicht schon damals gemacht?" Ja weil es da halt noch keine ARM Coprozessoren für das VCS gab. In der Demoszene wäre das jedenfalls nicht mehr "Retro" sondern nur noch "Wild" (also keiner anderen Kategorie zuzuordnen).

    Ich habe gerade so etwas hinter mir, allerdings für einen C=128 D und der Einbau ist komplett intern verdeckt. Dazu habe ich sogar etwas die Firmware gepatched, so dass ich das Reset-Signal auf dem IEC-Bus auswerten kann. Das sorgt bei mir dafür, dass ein Druck auf Reset dafür sorgt, dass bei der Floppy und SD2iEC die Geräte Adresse zurückgesetzt wird. Das kann die normale Firmware nicht, braucht man aber, wenn man in per Befehl 8 und 9 vertauscht.


    Der Fork ist auf github: https://github.com/SvOlli/sd2iec-lcd/tree/c128d-internal

    Im README steht ein bisschen über die Änderungen, im Vergleich zu einem normalen SD2IEC (LCD).


    Allerdings hatte ich auch mehrere verschiedene SD2IEC gekauft, und dann den genommen, der am besten für den Einbau gepasst hat. Und das würde ich auch hier vorschlagen: einen zu nehmen, der mindestens noch "Prev" und "Next" Buttons hat.

    I have allmost no idea what you are talking about.

    I was asking if anyone knows of a fork of SD2IEC that I should try to include. (fork = someone took to original code of SD2IEC added a new feature, like a new loader or the LCD is such an example)

    If so, please enable LCD support together with the new .crt handling. I'm a little desperate, because one of my SD2IEC has the new firmware, while the one with LCD hasn't. So filetransfer is still unhandy.

    This is done with the current version announced here yesterday. Downside: no binary releases, you have to compile it yourself.

    I have a very noob question: how to use the .crt files (I assume that its are cartridge (EPROM) dump files) on the SD2IEC?

    I noticed that Ingo did a change concerning the handling of .crt and .tcrt files, disabling the P00 header for those types. But that's just the handling of the files on the card, still you need completely different hardware to "run" them, like EasyFlash3 or KungFuFlash.


    A also stumbled over a fork that includes additional fast loaders for the C64 version of "Another World", as well as "Wings of Fury".


    So I went through some merge-a-rama to get to a new "includes-all" version. It compiles, but is completely untested otherwise. Will update my devices on the weekend or so...


    Anyone else knows any forks that I should also try to include? ;-)

    (And before anyone asks: the version for supporting the fast serial bus (from the C128) can't be done, as it is based on a very old version.)

    I forgot to mention that it only happens with the SDL version. GTK has the correct speed, but is at least for me less usable. But, setting the speed to 80% or 120% doesn't make any difference, it always is running at 60%, though the status bar is adjusting slowly to the correct values.

    this should be fixed now, i haven't it tested myself though.

    I finally managed to compile a Linux deb package for testing. The result is rather funny: is starts with 50 fps, then drops down to 40% in about 2.5 seconds, then gets back to 50 fps again, dropping to 40 ftps... and so on.


    Sorry for the delay...

    VICE 3.5 doesn't work for me at all on my Linux system. My monitor is only capable of running at 30 fps (cheap'n'old 4k). With VICE 3.5 now my emulated PAL C64 runs to 60% speed, as the C64 also runs at 30 ftps instead of 50. Switching back to 3.4 did the trick for me, so I'm stuck to it until I upgrade my display (not gonna happen anytime soon)...

    now that's weird. what happens if you use a custom fps as maximum speed?

    I forgot to mention that it only happens with the SDL version. GTK has the correct speed, but is at least for me less usable. But, setting the speed to 80% or 120% doesn't make any difference, it always is running at 60%, though the status bar is adjusting slowly to the correct values.

    VICE 3.5 doesn't work for me at all on my Linux system. My monitor is only capable of running at 30 fps (cheap'n'old 4k). With VICE 3.5 now my emulated PAL C64 runs to 60% speed, as the C64 also runs at 30 ftps instead of 50. Switching back to 3.4 did the trick for me, so I'm stuck to it until I upgrade my display (not gonna happen anytime soon)...

    I've uploaded the git repository to github: https://github.com/SvOlli/sd2iec-lcd. To keep things clean I'm using the master branch to keep in sync with sd2iec.de and use a branch name "LCD" for the LCD enabled variant. This is be the main branch seen in github's webview. I'm also thinking about to add about two or three other features (like disabling using OPEN 1,N,15,"H" : CLOSE 1). If I do, these will go into a third branch.


    Pull requests are very welcome.

    I synchronized my Arduino SD2IEC LCD project with your files and yes, works just fine. You did a great job.

    Thanks. This also means, I did the right thing. When I was about 70% done, I noticed, that I could achieve my main goal just be changing the configuration as evo2 is almost the same as the larsp config except that it uses PORTA for softiec instead of PORTC. So just changing 6 lines of code would've gotten me a working software. But I decided, if I do a "proper" job on completing the merge, this might help others as well.


    So you've made my effort worthwhile.

    Hallo!


    Ich habe mir vor längerer Zeit auf ebay eine SD2IEC gekauft, die zwar kein LCD hat, aber trotzdem die "evo2"-Firmware verwendet. Da ich damit auch mal gerne "Sam's Journey" auf meinem C-128D spielen wollte, habe ich mich hingesetzt, und den letzten Stand von SD2IEC mit der letzten Version von CapFuture1975 gemerget. Hier ist das Ergebnis. LCD kann ich ich nicht testen, weil ich halt keins habe, "Sam's Journey" läuft aber gut.


    Auf Wunsch kann ich das komplette Repository auch auf github hochladen, falls jemand noch etwas weiter basteln möchte.

    Files

    • sd2iec-lcd.7z

      (244.89 kB, downloaded 30 times, last: )

    Hallo!


    Ich hatte mich in letzter Zeit mit verschiedenen Lade-Beschleunigern beschäftigt. Dabei ist mir aufgefallen, dass in jedem YouTube Video die Leute ihr Handy zücken, die Ladezeit schlecht von Hand stoppen, dann aber die ungenaue Zeit auch gerne mit zwei Stellen nach dem Komma angeben. Um mal einen besseren Vergleich zu haben, habe ich mal ein bisschen Tooling gebastelt, mit dem man die Ladezeiten messen kann.


    Gemessen wird mit der TOD vom CIA, somit sollte die Messung genauer sein als jedes Handgestoppe.


    Zu haben ist der Kram als Sourcecode als auch als Binaries unter: https://github.com/SvOlli/timeload


    Viel Spaß damit,

    SvOlli

    Die Widerstandsnetzwerke sind richtig herum eingelötet?

    Eines der beiden ist falsch herum. m( Ich schwinge da morgen mal den Lötkolben und gebe dann ein Update.

    Jepp, das war es! Ich weiß nicht, wie oft ich gesehen habe, dass der Druck auf beiden in die selbe Richtung zeigt, aber gleichzeitig die "Pin 1"-Markierung außen ist, ohne zu schnallen, dass da was nicht passen kann.

    Danke für den Schubs in die richtige Richtung.

    Irgendeinen Tipp, wie ich das Problem einkreisen kann?

    Könntest Du Fotos der Ober- und Unterseite hier einstellen?

    So, hier sind sie. Die Lötstellen sind mit Lupe mehrfach geprüft. Es gab auch zwei Lötstellen, die ursprünglich "nicht ganz sauber" waren.

     

    Getestet hatte ich so, dass ich nur das komplette 1581 PCB getauscht hatte. Der Rest blieb gleich.

    Danke für's Reingucken!

    Hallo!


    Ich habe ein interessantes Problem mit meiner 1581replica: sie geht fast. Die Konfiguration ist Gotek-Laufwerk mit FlashFloppy und einem JiffyDOS ROM.


    Beim Einschalten macht sie alles wie erwartet, beide LEDs gehen an, eine kurz danach aus. Beim Datentransfer funktionieren aber nur wenige Bytes. Ein "LOAD" schicken geht, die Drive-LED geht an, aber danach "klemmt" der Bus Wenn ich den Statuskanal auslese, geht das manchmal auch, dann bekomme ich die 73er-Meldung (in meinem Fall von JiffyDOS), aber beim zweiten Mail klemmt es dann wieder. Manchmal auch beim ersten Mal. Meine "echte" 1581 funktioniert mit dem Gotek-Laufwerk und dem selben Netzteil, daran kann es also nicht liegen.


    Irgendeinen Tipp, wie ich das Problem einkreisen kann? Viel mehr Messtechnik als ein Volt-/Amperemeter ist allerdings nicht vorhanden.

    Moin!


    In Anbetracht der 1581replica habe ich ein Tool rausgekramt, welches ich damals (also Anfang '90er) für meine 1581 geschrieben habe. Vor einer Veröffentlichung habe ich den Sourcecode noch nach ca65 portiert. Das Tools ist nicht als Komplettlösung gedacht, sondern macht das, was ich damals gebraucht, aber kein Tool zu hatte:

    • Erstellen von Subdirectories
    • Sector Editor
    • Undelete durch Analyse der Linker Bytes der Blöcke (die Einträge müssen per Sector Editor erstellt werden)
    • Mehr Platz durch verschieben von Daten in die letzten 20 Directory Blöcke
    • Error Scan, weil ich immer mal Probleme mit Disketten hatte

    Der Sourcecode ist nicht schön, weil ich damals einen Datenverlust hatte, und zumindest Teile aus einem Reassembly ziehen musste. Nichtsdestotrotz ist jeder eingeladen, an dem Code rumzubasteln und mir Änderungen zu schicken.


    Der Sourcecode gibt es auf githhub, das Binary ist dort auch mit eingecheckt und kann auch einzeln runtergeladen werden.


    Viel Spaß und ich hoffe das Tool hilft etwas,

    SvOlli