Posts by thierer

    Danke Dir. Auch dazu fehlt mir leider die Hardware.

    Du hast also keinen Zugriff auf die im Titel erwähnte "Zoom Floppy" oder ein ähnliches Interface? "Nur" C128D, mehrere C64 und mehrere 1541?


    Naja, es wird dann leider gar nichts gelesen bei einer 1541 Floppy, noch nicht mal das Load"$",8 oder Load "*",8,1

    Das bedeutet aber nicht unbedingt, dass "gar nichts" gelesen werden kann, sondern vermutlich nur, dass die Sektoren 18/0 oder 18/1 nicht gelesen werden können.


    Was kommt denn konkret für eine Fehlermeldung nach LOAD "$",8?


    Falls du nicht weißt, wie du die Fehlermeldung mit Bordmitteln auslesen kannst, siehe hier: https://www.c64-wiki.de/wiki/F…ehle#Fehlerkanal_auslesen

    Ich habe ein kleines Programm angepasst, das ich mal mit diskimage.c für einen ähnlichen Zweck geschrieben habe.

    Ach von dir stammt diskimage.c? Das hatte ich auch schon mal als Vorlage für ein eigenes Programm verwendet.

    Hab dabei einiges gelernt. Vielen Dank für das Programm.

    Nein, diskimage.c ist nicht von mir, sondern von Per Olofsson (siehe Homepage). Ich habe es nur für mein eigenes Programm verwendet und wollte bei der Gelegenheit darauf hinweisen, weil ich es für solche Zwecke nützlich finde.

    Ich habe ein kleines Programm angepasst, das ich mal mit diskimage.c für einen ähnlichen Zweck geschrieben habe. Das konkrete Problem ist nicht ganz trivial, weil sich die Dateinamen teilweise nicht in den ersten 16 Zeichen unterscheiden und es deshalb bei einzelnen Images zu Kollisionen kommt. Das habe ich so gelöst, dass ich solche Dateien in das nächste Image verschiebe. Das ist nicht ideal, weil 1. die Datei dann nicht da steht wo man sie gemäß Alphabet erwarten würde und 2. sich die Dateien auch nicht anhand des Dateinamens unterscheiden lassen. Eine bessere Lösung war mir aber auf die Schnelle zu viel Aufwand. Ich habe das Konvertierungsprotokoll beigefügt, daran kann man erkennen, wo welche Datei steht.


    Ich habe das Ergebnis nur stichprobenhaft geprüft, falls irgendwas fehlt oder nicht stimmt gib Bescheid.

    1 Min 40? Das heisst, es unterstützt den Fast-Modus.


    Könntest du mal schauen, welche OpenCBM-Version da verwendet wird? Mit meiner Version habe ich den Fast-Modus nicht ans Laufen bekommen.

    Ich glaube, das ist ein Missverständnis. Dem OP geht es wohl darum, ein D81 Image autark auf einem PC - mit dem eingebauten Floppy-Laufwerk - im 1581-Format auf eine Diskette zu schreiben (das ist jedenfalls das, was das eingangs erwähnte "1581Copy" zu machen scheint). Also ganz ohne CBM-Hardware.


    Das Geheimnis des Erfolges mit PRG-Mover ist vermutlich, dass es das Programm "1581Disk Utility" mitbringt. Offenbar eine "modernere" (2006 :D) Variante von "1581Copy" (ist auch auf der 1581Copy-Homepage unter "More modern alternatives" verlinkt).

    2 spontane Ideen:

    • Vielleicht ist das Programm zu alt, um lange Dateinamen zu unterstützen? "turrican.d81" passt zwar noch in 8.3, allerdings ist das vielleicht gar nicht der vollständige Name? Oder der 8.3 Dateiname ist trotzdem anders, weil es eine Kollision in den ersten 8 Zeichen gibt bzw. gab? Windows 95 ist ein Weilchen her :) aber wenn stimmt was ich auf die Schnelle gefunden habe, dann kann man sich die kurzen Dateinamen mit "dir /x" anzeigen lassen.
    • Was unter Windows auch immer wieder für ähnlich mysteriöse Fehler sorgt, ist wenn der gesamte Pfad inkl. Dateiname zu lang ist. Falls es ein weit verschachteltes Unterverzeichnis ist, dann kannst du es mal in einem anderen Verzeichnis probieren.

    After that work I found I can now reproduce anything the CIA reports back on the Timer A output when in CNT count mode, using this input circuit: CNT is an input to a normal D-type Flip-Flop with an Asynchronous reset input. This feeds another flipflop that synchronizes the detected posedge to the PHi2 clock domain, and its output also resets the edge detector. So during the actual internal count pulse (when cnt_rr=1), you can do whatever you want on the CNT input - it is ignored.

    The Verilog you posted suggests that the second flip flop is clocked from the negative PHI2 edge, which matches exactly what I observed, doesn't it? The time between the positive CNT edge and the times that I marked "1" is the period between the two events. The difference between the Timer A logic you describe and the SR logic would be that the latter takes one PHI2 cycle longer.


    The funny thing is, the duty cycle issue you mention doesn't seem to come up in my tests for timer A. The rising edge is detected regardless if it is just a very short 1->0->1 pulse (like in your graph) or if it is a very short 0->1->0 pulse, or of it already goes 1->0 in the cycle before the posedge. Maybe it is a Serial Register exclusive issue, to do with that trasparent path I found. I will research that.

    I think that's a misunderstanding. You're probably referring to what I wrote in #31? Maybe "duty cycle" was bad wording. I was talking about the behaviour of the 6526 when sending. It sets CNT low at the beginning of a bit cycle and then does one low -> high transition at 50% of the bit cycle and keeps CNT high for the rest of the bit cycle. What I meant is that this transition has to be earlier than the 50% mark of the bit cycle because in the worst case it can take ~2,5 PHI2 cycles from the positive edge of CNT until SP is sampled (as outlined in #41) while 50% of the bit cycle is only 2,0x PHI2 at the highest data rate.


    That does *not* mean, that something like this, with only a short positive CNT pulse, would not work:

    Code
    1. |<- >2 phi2 cycles ->|
    2. PHI2 |____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾
    3. CNT ‾‾‾‾‾‾‾‾|__|‾‾|_____________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
    4. SP ‾‾‾‾‾‾‾‾|___________________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
    5. ^ ^
    6. 1 2

    Is that what you meant? I never checked anything like that, I only experimented with having the CNT low -> high transition at different points in the bit cycle.


    What I don't understand is the "... or of it already goes 1->0 in the cycle before the posedge" part. I guess "1->0" refers to CNT (?), but "posedge" of what? PHI2? Shouldn't this be "negedge" then? In that case I would agree (it's what my "diagram" above shows, right?).

    So, I conclude from your FPGA experiments, you've seen max transfer rates close to 2 phi2 clocks per bit using a 6526R4 in a C64 as input, when you first phase-align the external FPGA with the chip. You then also make CNT only high for half of a PHI2 cycle, followed by 1.5 cycles low. Is that correct?

    No, a short CNT low phase followed by a 1,5 PHI2 cycle high phase.


    This is what the "best case" would look like for a transmission of a "0" bit followed by a "1" bit:


    Code
    1. |<- 2 phi2 cycles ->|
    2. PHI2 ‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾
    3. CNT ‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|_
    4. SP ‾‾‾‾‾‾‾‾|___________________|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|_
    5. ^ ^
    6. 1 2

    From what I (think to...) understand, the 6526 would register the positive CNT edge at the negative PHI2 edge at "1" and sample SP 1,5 cycles later at the second positive PHI2 edge at "2". The whole CNT/SP transfer cycle is 2 PHI2 cycles. You could even go slightly faster for one bit by making the CNT "low" phase shorter, but that doesn't gain you anything, because if the time for 1 bit isn't a multiple of a PHI2 cycle, you lose the optimal phase offset for the next bit(s).


    And this is the "worst case":


    Code
    1. |<- ~3 phi2 cycles ->|
    2. PHI2 |____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾|____|‾‾‾‾
    3. CNT ‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾|__|‾‾‾‾‾‾‾‾‾‾
    4. SP ‾‾‾‾‾‾‾‾|___________________________|‾‾‾‾‾‾‾‾‾‾‾‾‾
    5. ^ ^
    6. 1 2

    As the negative PHI2 edge just misses the positive CNT edge, SP is sampled ~1 PHI2 cycle later than in the "best case". So in order to work with all possible phase offsets, you have to make SP valid for one more PHI2 cycle.


    I actually don't know much about chip design, that's why I can't really follow all your explanations. I merely took a black box approach and checked what signals lead to which bits being sampled in the SR. I can't really comment on what the actual design would have to look like to lead to this behaviour.


    Regarding the IRQ issue: I only brought it up because I thought that you said you found that the SR IRQ has a similar issue as the "timer b bug". As that apparently was a misunderstanding, I wouldn't read too much into that. I didn't do enough research to be confident that the IRQ really wasn't set for the SR. In the end it could well be something as simple as a bad connection on the IRQ probe.

    I have'nt seen if you're looking at sending or receiving bits from the 1571, or both? Do the issues also occur at say lower speeds?

    I actually haven't experienced the problems myself, as I don't even own a 1571. So strik would need to comment if the errors also happen at slower speed (and maybe also when the 1571 is sending).


    I only did some low level tests to learn about the timing requirements of the CIA when receiving at maximum data rate (because that's what the xum1541 firmware is communicating at).

    I mean phi2 clocks (not CNT clocks).

    I understand that. The reason why I was asking was your statement "SP is really still sampled after 3 clocks", while my understanding is that it's sampled after 3 half-cycles of PHI2 (see my reasoning in #25).

    Leaving the 6526 at DC 0Hz for a very long time like a few seconds or more, I have seen some weird stuff happen though. Like it resetting itself. Not sure if that is an artifact.

    I think that's true for all the NMOS chips. (In contrast to the WDC versions, where I think you can halt and resume the clock at will).

    In the test above there is a sequence somewhere halfway showing what I mean: (I hope pasting this works): This is the same information as above, but just run through verilog to create a waveform. At the bottom are 2 registers from my own verilog model, where you can observe the shifter shifting and that the IC sends out CF as value of SDR, which is one cycle too late. The proper value SDR should have been was 67.

    If I understand that correctly, the Verilog isn't supposed to model the workings of a real CIA but the equivalent of what you're doing with your Arduino code, right? Otherwise I don't understand it because the original chip takes 4 PHI2 cycles per bit when sending, while the waveform you posted seems to have only two cycles per bit.

    Yes, there may be a bug like the Timer B bug - I would then also only expect those bugs in the so-called "old" 6526R4. But who knows. So far I have not seen this bug in my tests - but if it exists I will be able to find it. But if it is a bug similar to the timer B bug, it would present itself at any speed of operation of the serial port.

    FWIW, my C64 has a 6526R4, so that's what I used. It then probably wouldn't apply to the CIAs in a 1571, though.


    At phi2/2 speeds, SP is really still sampled after 3 clocks, so in the same cycle the next CNT edge is created you can set the SP value for the *previous* bit.

    So here with "clocks" you mean clock changes (not clock cycles), right?


    I'm fairly sure the IC was not intended to go this fast - the datasheet mentions SP is captured on posedge. That is true only if CNT is lower than PHI2/4. And that aligns with the max speed another 6526 on the same clock frequency is able to produce.

    I'm not sure that's what you mean, but in my experience it is *not* possible for the CIA (at least the 6526R4 that I used) to reliably receive from a CIA running at the same clock speed at the highest data rate (ie timer a == 1) . In the worst case it takes 2,5 clock cycles (of the 4 clock cycles for one bit at maximum speed) from the rising edge of CNT until SP is sampled (I just realised in #25 I wrote that the worst case is 3,5 clock cycles, that is not correct).


    As when sending from the SR the CIA uses a CNT duty cycle of 50% (2 clock cycles), the remaining 2 clock cycles are not enough for the receiving CIA to correctly sample the bit for all possible phase offsets between CNT and PHI2. (To correctly receive a bit, the CIA is happy with a much shorter low CNT phase than 2 clock cycles. The xum1541 firmware for interfacing with the 1571 uses a ~75% duty cycle for CNT, that's why the transfer generally works, even at the highest speed).

    I have to admit that I don't fully understand the implications of the debug output you provided.


    As I understand it, you are suggesting that a similar behaviour to the "timer b bug" might exist for the SR IRQ? How I understand the "timer b bug" (I had to look it up, please pardon my ignorance...) it means that the IRQ flag is not set if the ICR is read right before the flag would be set?


    That would make a lot of sense: What I did in my tests is that I had some code running on the C64 which checked the ICR in a loop and then put the content of the SR in PB, so the FPGA could read it check if this matched the value it sent.


    And checking the ICR in a tight loop is exactly what the receive routine of the SRQ nibbling code (that exhibits the bug, that strik is currently investigating) is doing.

    WHen I clock SDR in any faster than CNT three cycles low, three cycles high, then I get unreliable state. Something is still working but not reliably. This must mean the exact internal state is meant to go no faster than 3 cycles (which is 4 cycles of an external part which then could be 3 cycles occasionaly due to clock drift between systems)

    Motivated by @strik's recent work on the SRQ-transfer for opencbm that he mentions, I recently did some tests by hooking up a FPGA board to my C64's CIA and using different timings to check which of them are relevant when receiving into the shift register.


    My impression was that after the positive edge of CNT the CIA samples SP on the second rising edge of PHI2 following the next falling edge of PHI2. That's true even if CNT goes low again before this time (but a second rising edge of CNT before the data is sampled seems to kill the cycle). This would suggest that it takes 1,5 (best case) to 3,5 (worst case) PHI2 cycles to sample the data, depending on the phase difference between PHI2 and CNT. And I could in fact "reliably" transfer data into the SR with about double the nominal rate (that it, 2 x PHI2 instead of 4 x) when I aligned CNT to just before the negative PHI2 edges. (I didn't transfer MBs but only KBs, but I found the results to be pretty reproducible in either way).


    I also had cases where the SR would receive the correct value, but the IRQ bit wouldn't be set. I haven't found what could cause that, though, and I suspect it might well be a bug in my test setup.

    Gerade frisch kompiliert.

    Auch installiert oder direkt aus dem Verzeichnis gestartet? Oder anders gefragt: Ist sichergestellt, dass der Eintrag "location" unter "[xum1541]" in "/etc/opencbm.conf" auf die neu übersetzte Version zeigt? Bitte prüfe mal das Dateidatum.


    Außerdem wäre noch die Linux-Kernelversion interessant (uname -a).


    Zum Segfault fällt mir spontan nur auf, dass du offenbar nicht die neueste libusb Version installiert hast. (Es sollte trotzdem nicht crashen, könnte aber erklären, warum der Fehler zB bei mir nicht auftritt).

    Gibt es weitere Ideen?

    Ideen ja, aber nichts handfestes :)


    Ich fuhr den Rechner runter, wollte ihn neu starten: Keine Reaktion, der Rechner wollte nicht starten! Ich habe alles mögliche Probiert, er wollte partout nicht. Ich spielte an den Tasten rum, machte ihn für längere Zeit stromlos: Nichts.

    Wie äußerte sich "wollte nicht starten" denn genau? Beim Druck auf den Einschaltknopf tut sich gar nichts, oder er bleibt im BIOS Bootscreen oder sonst wann hängen?


    Das mit dem größeren Mauszeiger und dem automatischen Klicken hört sich für mich nach einer accessibility Einstellung an? Ich kenne mich da aber nicht aus. Kann ja auch sein, dass die Einstellung durch eine bestimmte Eingabe (zB Maustaste lange drücken, so ähnlich wie das Halten der Umschalttaste) aktiviert wird und das durch irgendwelche Geistereingaben passiert ist.


    Ich weiß nicht ob das sein kann, aber sonst fällt mir noch ein, dass vielleicht die Stromversorgung (also 230V) dort ein Problem hat und so starke Störungen durch die Netzteile nicht weggefiltert werden können. Das könnte vielleicht auch den defekten Powerline-Adapter und die Kalibrierungsprobleme des Smartboards (und ggfs. falsch erkannte Eingaben die einen accessibility Modus aktivieren) erklären. Wenn ähnliche Probleme also nicht auch in anderen Räumen auftreten, dann vielleicht mal alles da einstecken.


    Das erklärt nicht, warum der Rechner bei dir zuhause erst gar nicht startet, aber so richtig hundertprozentig reproduzierbar kann das ja nicht sein, sonst hätte er in der Schule (mit mutmaßlich angestecktem Hub) auch nicht gestartet? Vielleicht ist das ja ein anderes oder ein Folge-Problem.


    Sonst könnte das Netzteil des Computers selbst auch ein Auslöser sein.