1541-Emul (zweiter Anlauf)


  • Diddl
  • 28706 Aufrufe 147 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • sauhund schrieb:

    allerdings will man aus verschiedenen gründen das die "tailgap"

    Warum? Kannst mir die Gründe nennen? Die diversen Quickformat Routinen machen das ja auch nur teilweise.


    Der/die Entwickler des 1541-DOS haben schon sehr schräge Sachen gemacht: Nach einem WRITE wird ja der Jobcode auf VERIFY geändert. Da kommt es zu folgender rechenintensiven Sequenz:
    • Blockdaten in GCR enkodieren
    • Block WRITE
    • Blockdaten in GCR dekodieren
    • Blockdaten in GCR enkodieren
    • Block VERIFY

    Mit etwas Mühe hätte man sich einmal dekodieren und enkodieren sparen können. Zumindest wenn man 1,5 Buffer frei hätte. Verify sofort ausführen geht natürlich nicht, da man sonst fast eine ganze Umdrehung warten muss ...

    Ich glaube einfach, viele Dinge wurden einfach nur schlecht gemacht! Wie bei den meisten kommerziellen Dingen ...
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Nach Tests mit verschiedensten Disketten Images, ist mir ein böser Bug aufgefallen. Auf der Suche nach der Ursache des Bug, habe ich (für mich) gänzlich neue Erkenntnisse gewonnen:

    Bis heute habe ich fest daran geglaubt, dass in einem GCR Datenstrom kein FF vorkommen kann. Weil FF ist SYNC und wird von der Leseelektronik gesondert ausgewertet.

    Offenbar ist das aber ein böser Irrtum, anscheinend kann schon FF reguär vorkommen im GCR Stream!

    Wenn in einem Sektor zb. die Bytefolge

    Quellcode

    1. 05 e7 07 07
    vorkommt, dann wandelt die GCR Encoder Funktion das in die folgende GCR Bytefolge

    Quellcode

    1. af 94 ff 5d 57
    . Dieses FF passiert, weil die zwei 5 Bit Gruppen 01111 und 11110 ungünstig zusammenfallen.


    Ich muss nun meine SYNC Erkennung etwas überdenken ...

    Es tut zwar, wenn man auf mindestens zwei FF testet. Aber vermutlich ist die einzig richtige Variante ein Test auf zehn 1 Bits im Bitstrom.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Wenn ich den Wiki-Link richtig verstanden habe, willst Du für die I/O-Geschichte sowie SD usw. das arm2iec-Board nutzen? Sag Bescheid, wenn Du Betatester brauchst, dann kaufe ich mir das Board und pack das auf mein arm2IEC.....
    Wäre ziemlich genial, wenn das Teil irgendwann die ganzen Fastloader unterstützt, die in den Demos genutzt werden...würde das Teil zur idealen Ergänzung des C64DTV machen, ne Ultimate wäre da echt Overkill....
  • CrazyIcecap schrieb:

    Wenn ich den Wiki-Link richtig verstanden habe, willst Du für die I/O-Geschichte sowie SD usw. das arm2iec-Board nutzen?

    Ja genau, mein Prototyp ist ein F407 Discovery + ARM2IEC Hardware.

    Die ARM2IEC Hardware bietet all das, was dem Discovery fehlt: SD Karte, IEC Anschluss, Parallelport, Taster, DIP Switch, Serialport (für debugging).


    CrazyIcecap schrieb:

    Sag Bescheid, wenn Du Betatester brauchst, dann kaufe ich mir das Board und pack das auf mein arm2IEC.....

    Ja, Betatester sind sehr wichtig! Programmierer sind denkbar schlechte Tester im Normalfall. Allerdings wird das wohl noch einige Zeit brauchen. Zur Zeit läuft das nur auf meinem PC, weil ich mich da viel leichter tu mit debugging. Am Discovery gibt es noch sehr viel zu tun ...


    CrazyIcecap schrieb:

    Wäre ziemlich genial, wenn das Teil irgendwann die ganzen Fastloader unterstützt, die in den Demos genutzt werden

    Genau das ist das Ziel. Es soll möglichst 100% wie eine 1541 reagieren, und das auch noch exakt mit derselben Geschwindigkeit.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Wunderbar! Trag mich als Tester ein :)
    An Hardware habe ich die klassischen Brotkästen und nen umgebauten DTV, und bei nem Kumpel steht noch ein C128D.

    unseen: Ach wat, das folg klassischer Commodore-Tradition, Turmbau zu Babel gabs doch schon in 128D, A1000 und A2000 :bgdev
  • Unseen schrieb:

    Das Konstrukt sieht bestimmt lustig aus...

    Prototypen sehen immer lustig aus.

    Aber die Alternative ist, alles auf Lochraster oder Steckboard aufzubauen. Da gefällt mir die Lösung mit dem ARM2IEC schon viel besser.


    Und wenn es erst mal läuft, vielleicht macht uns einer der Hardware Profis hier eine schöne Platine ...
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Das Schaltbild rund um die Schreib- Leseelektronik der 1541 ist mir ein Rätsel.


    Wie läuft das denn ganz genau:

    Frage 1: Wenn das DOS ins PCR des VIA schreibt um das CB2 auf low zu setzen (umschalten auf schreiben), fängt die Floppy dann sofort an zu schreiben oder wartet sie das nächste logische "Byte ready" ab? Betrifft der Schreibvorgang dann das nächste Byte oder gibt es da weitere "Verzögerungen"?

    Frage 2: Das "Byte Ready" Signal beim Lesen wird ja durch zählen von 8 GCR Bits erreicht. Gezählt wird ausgehend von einem SYNC ab dem ersten 0 Bit. Deshalb darf man ja nicht jedes beliebige Byte schreiben nach einem Sync (Headerbeginn und Blockbeginn ist ja fix mit 7 und 8 ). Da nur maximal zwei Nullen vorkommen kann sich der Byte Ready ja immer schön an den 1er synchron halten. Anders beim Schreiben, ich nehme an das funktioniert "freilaufend". Ist das soweit richtig? Geschrieben wird ja immer solange CB2 low ist, und das Schieberegister wird alle 8 Bit neu geladen. Zugleich wird "Byte Ready" gesendet, also das V Bit gesetzt. Wird da beim Umschalten von lesen auf schreiben was spezielles gemacht? Erfolgt die Umschaltung auf Schreiben erst, wenn das Lesen von 8 Bits abgeschlossen ist? Oder etwa sofort wen CB2 auf low geht.

    Frage 3: Beim Umschalten von schreiben auf lesen, erfolgt das sofort oder auch erst wenn die aktuelle 8 Bit Sequenz abgeschlossen ist?


    Ich erzeuge aus dem D64 Image synthetische GCR Daten. Die werden auch anstandslos gelesen von der virtuellen 1541. Beim Schreiben jedoch habe ich eine Veschiebung von drei Bytes zum Header hin. Es wird also drei Bytes zu früh begonnen. An sich macht das gar nichts, es funktioniert alles tadellos soweit, es stört mich nur weil es nicht perfekt ist und weil ich da noch einen Emulationsfehler orte. Was sagen die Experten dazu? Leider bin ich nicht in der Lage festustellen, wo der Fehler eigentlich liegt und wie ein reales Laufwerk arbeitet. Bzw. war ich bisher zu faul, einen 1541 Code zu schreiben, der mir die nötigen Antworten gibt. Bzw. hoffe ich, dass mir jemand weiterhelfen kann, ohne dass ich da Analyse Arbeit reinstecken muss.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    Das Schaltbild rund um die Schreib- Leseelektronik der 1541 ist mir ein Rätsel.

    Tip: Schau nicht in den Schaltplan der 1541 sondern in den der 2031 - die hat zwar einen anderen Bus, aber die gleiche Leseelektronik wie die allersten 1541er, bevor daraus ein grosser MOS-IC wurde. In der 2031 war das noch eine Sammlung diskreter 74xx-Logik.

    Ausserdem gibts im Netz irgendwo eine 3rd-Party-Reparaturanleitung für die 1541 (IIRC war es "SAMS Computerfacts 1541 Disk Drive"), die die Funktion der Leseelektronik ein wenig erläutert.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Projektfortschritt:

    Es hat jetzt einige Zeit gebraucht, bis ich mich in das Discovery 32F4 eingearbeitet habe. Aber jetzt ist endlich die Basis geschaffen, dass ich komfortabel mit dem 32F4 werkeln kann. Ich habe jetzt eine ähnliche Software Basis wie bei den guten alten Atmega Controllern ...

    Ich bin echt begeistert von dem Teil! Wenn man sich erst mal mit dem ST spezifischen Dingen herumgeschlagen hat, kommt man hervorragend damit klar. Und man hat um 16,70€ eine supergünstige und hochperfomante Entwicklungsumgebung. :D
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Wäre schön wenn jemand eine Platine basteln könnte, wo man das Discovery drauf stecken kann. Donald?



    Es müsste so organisiert sein wie das ARM2IEC:
    • Zwei IEC Buchsen + Bus Interface
    • optionaler Parallelkabel Anschluss
    • SD oder µSD Slot
    • 5 x Taster
    • 4 X DIP Switch
    • eventuell 4 x LED (nicht notwendig weil das Discovery eh 4 LED hat)
    • eventuell den optionalen LCD Connector


    Die µSD ist am SDIO Interface angeschlossen: SDIO.pdf


    Das Board zusammen mit einem Discovery wird eine perfekte 1541 Emulation, mit all seinen Stärken und Schwächen. Es wird auch SpeedDos Kernel und Jiffy Kernel laufen. Später eventuell auch ein Prologic, Dolphin oder Prof-DOS Kernel.

    Es wird niemals das können, was die die Ultimate-II bietet, und daher auch keine Konkurrenz dazu sein. Es ist einfach nur ein low-cost Ersatz für die 1541. Die Emulation wird ebenso kompatibel, wie der VICE mit "true drive".
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung