Projektvorstellung: SDrive-MAX

  • retro-larry schrieb:

    Dazu kann ich sagen, nein, sind sie offensichtlich nicht., denn bei Nutzung von Divisor 0 bis 3 kann nicht weiter nach dem sdrive-Menü gebootet werden (getestet mit einem unverbauten und einem gepatchten 130XE).

    Das könnte auch an den 1nF Kondensatoren liegen, die Atari zwischen Masse und Data-In bzw. Data-Out gehängt hat. Diese verhndern einen Divisor 0...3 oder auch 4 (je nach Rechner) recht zuverlässig.

    Entferne die beiden Kondensatoren C77 und C78. Bei allen XL Modellen sind die ganz oben rechts in der Ecke unterhalb der SIO-Buchse. Bei den XE Modellen sind die rechts vom POKEY in der Ansammlung von Widerständen und Kondensatoren, da mußte etwas suchen oder auspiepen.

    Mit entfernten Kondensatoren ist bis Divisor 2 immer stabil möglich - darüber hinaus, also bis Divisor 0, ist dies stark von der Hauptplatine als auch dem POKEY an sich abhängig. Es gibt 7 verschiedene Hersteller der POKEYs, leider gibt es sogar innerhalb eines Herstellers starke Schwankungen, so daß man nicht pauschal sagen kann, alle "OKI" POKEYs sind gut etc.pp. - Ausprobieren.

    Gruß, Jürgen
  • tfhh schrieb:

    retro-larry schrieb:

    Dazu kann ich sagen, nein, sind sie offensichtlich nicht., denn bei Nutzung von Divisor 0 bis 3 kann nicht weiter nach dem sdrive-Menü gebootet werden (getestet mit einem unverbauten und einem gepatchten 130XE).
    Das könnte auch an den 1nF Kondensatoren liegen, die Atari zwischen Masse und Data-In bzw. Data-Out gehängt hat. Diese verhndern einen Divisor 0...3 oder auch 4 (je nach Rechner) recht zuverlässig.
    Du hast vollkommen Recht - nicht nur könnte, sondern das liegt an den beiden besagten Kondensatoren. Ich besitze nämlich auch ein SIO2SD von Lotharek und im von mir erwähnten "gepatchten XE" sind bereits u.a. C77 und C78 entfernt. Und so kann mein gepatchter XE mit dem SIO2SD wunderbar den Divisor 0 benutzen :)
    Wenn Ihr also einen XE sucht, der ggf. einmal sdrive.-max unter Steroide testen soll: Meiner steht stets zur Verfügung!
  • retro-larry schrieb:

    Verzeih', ich will da keine Grundsatzdiskussion vom Zaun brechen oder gar Klugscheißen, denn dabei dürfte ich vermutlich den Kürzeren ziehen ;) Aber ist es nicht genau andersherum? Denn die Konverter und Emulatoren sprechen (fast immer) davon, dass sie WAV-Files (also reines Audio) in "das kompakte CAS-Format" konvertieren würden, bzw. "das kompakte CAS-Format" unterstützen (also das mit dem FUJI-Header),
    Ich versuche ja nur zu vermeiden, dass es für die Zukunft noch mehr Durcheinander bei den Formaten und deren Extensions gibt, wo "wir" doch gerade dabei, eine tolle neue Hardware ins Spiel zu bringen und noch dabei sind, Features und Spezifikationen festzulegen...
    Tja, in meinem Archiv wars halt bislang so, aber ich lasse mich auch eines besseren belehren. Es gibt sowohl ein Tool WAV2CAS, als auch WAV2TAP. Einen Standard gibt es nicht, demnach ist es wohl immer im Ermessen des Entwicklers für das jeweilige System, Ich möchte mich da gerne an den meistverwendeten Standard anpassen.
    Wer die Ironie findet, darf sie behalten ^^
  • Hast Du zu WAV2TAP einen Link? Ich finde darüber nur Tools für Spectrum und andere. Und Atari-TAP-Dateien für sind zumindest mir noch nicht untergekommen.
    Wenn ich mir andere Tools anschaue, bspw. a8cas und Turgen, erzeugen diese CAS-Dateien mit besagtem FUJI-Header. Hier wird das auch schön beschrieben.
    Insofern wäre ich dafür, meine seltsamen BIN-Dateien als .TAP zu behandeln - also quasi "Binarys ohne weitere Header/Informationen".

    Hier (unter Punkt 9.1) gibt es auch noch eine schöne Liste der nicht-offiziellen, aber mittlerweile üblichen Fileextensions. Dort wird auch nochmal erwähnt, dass BIN-Dateien ROM-Dumps wären, so wie ich das noch in Erinnerung hatte. Woran hast Du erkannt, das meine BINs CAS-Dateien seien?
  • Am Dateianfang, das entspricht einem gültigen Atari Bootblock:


    Quellcode

    1. 00000000 00 20 fa 2f 00 30 a0 d3 a2 3c a9 07 20 5c e4 a9
    Flags $00, $20 blocks to load at $2ffa, init at $3000, and following $a0 is opcode for LDY(boot continuation entry at offset $6).


    Quellcode

    1. 00000000 00 62 00 2f 1a 2f a9 00 8d e7 02 a9 60 8d e8 02

    Flags $00, $62 blocks to load at $2f00, init at $2f1a, and following $a9 is opcode for LDA.

    EDIT: Bei einem Disk-Image werden meist nur 3 Blocks geladen, den Rest macht der Bootloader selber, daher der Unterschied.

    Ich meine das Spektrum Tool, hab das jetzt nicht nur auf Atari bezogen, aber scheinbar macht es je nach System wieder jeder anders...
    Wer die Ironie findet, darf sie behalten ^^
  • retro-larry schrieb:

    Wenn ich mir andere Tools anschaue, bspw. a8cas und Turgen, erzeugen diese CAS-Dateien mit besagtem FUJI-Header. Hier wird das auch schön beschrieben.
    Insofern wäre ich dafür, meine seltsamen BIN-Dateien als .TAP zu behandeln - also quasi "Binarys ohne weitere Header/Informationen".

    Ich hab jetzt noch meine alten Disks durchgesehen, speziell welche mit Programmen für Tape2Disk copy usw., und da war damals am Atari schon die Erweiterung .CAS gängig für Tape-Images. Z. B. hab ich eine Disk gefunden mit sog. COM-Loadern drauf, CKCOS.CAS, HAPYCOS.CAS, RTMBLC.CAS usw., die man damals zuerst auf Tape geschrieben hat, und anschließend ein COM-File.

    Daher ist bei mir die Erweiterung so drin, und ich finde es ehrlichgesagt ziemlich blöd, daß man später diese Erweiterung dann für dieses FUJI-Format wiederverwendet hat. Und man findet im Netz aktuell tatsächlich hauptsächlich CAS-Dateien im FUJI-Format...

    Also was tun, sprach Zeus: Meine Idee wäre jetzt beide Erweiterungen erlauben, und auf den FUJI-Header prüfen. Sollte der vorhanden sein, muß ich die Datei ablehnen, denn dieses Format braucht definitiv eine Tape-Emulation, und das hab ich nicht vor mit einzubauen(zu aufwändig, und die lange Ladezeit will sich doch keiner mehr antun).
    Wer die Ironie findet, darf sie behalten ^^
  • Vielen Dank für die Erläuterung der Bootblock meiner BIN-Dateien. Da klärt sich nach so langer Zeit doch noch einiges auf :)
    Wegen Deines Vorschlags zur Dateierweiterung: CAS für unsere Kassetten-BIN-Dateien mit Header-Prüfung geht völlig in Ordnung. Wie es Dir besser passt im Code umzusetzen. Das ist ja kein Muss-Feature, weshalb Du das Rad neu erfinden müsstest. Wenn es im Code berücksichtigt werden würde, würde sdrive-max aber allmählich zur Eierlegenden Wollmilchsau werden. Und Alternativ ginge ja auch noch TAP, aber damit würde man ja wieder eine neue Erweiterung einführen.
    Ich denke ja, dass wir wohl die einzigen Wesen auf diesem Planeten sind, die solche BIN-Dateien und das sdrive-max besitzen und nutzen :)

    Hias habe ich heute wegen der Highspeed-SIO-Patches kontaktiert. Ich werde berichten...falls er sich hier (oder bei Dir) nicht selber zu Wort meldet.
  • Antwort von Hias, unserem SIO-Held!

    Matthias Reichl schrieb:

    Ich hab mal meine alten Sourcen in einen git tree gefüttert,
    die Commits nach funktionalen Änderungen gegliedert und auf
    github gepusht: github.com/HiassofT/sdrive-firmware

    Damit Highspeed SIO bis divisor 0 geht braucht's nur diesen
    einen Commit:
    github.com/HiassofT/sdrive-fir…90ac66bc5e77801826344309b

    Der Delay Commit ist auch hilfreich, könnte evtl noch andere Highspeed
    SIO Implementierungen als qmeg OS betreffen
    github.com/HiassofT/sdrive-fir…dd74b00a638ddb6e5e78c1594

    Ein Haken mit der Arduino Implementierung ist, dass im SDrive der Atmel
    mit 14.318MHz getaktet ist, im Arduino aber mit 16MHz. Da mein
    bitbang Code auf 14.318MHz ausgelegt ist müsste der an den anderen
    Takt angepasst werden.

    Zum Empfangen wird weiterhin die UART im Atmel verwendet und
    ad hoc weiss ich nicht ob man die bei 16MHz genau genug auf die
    Atari Datenraten konfigurieren kann - bei 14.318MHz ging sich das
    wunderbar aus.

    Wenn Du eine Kontaktadresse zu kbr hast leite ihm einfach die
    Infos weiter, vielleicht kann er damit ja was anfangen :)
  • Oh jeh, da passt nichts mehr zusammen, hab ich wohl doch schon zu viel gewütet im Code :/
    Das muß man Zeile für Zeile durchgehen, die richtige Stelle suchen usw., das macht Arbeit, und irgendwie gefällt mir das auch alles nicht so ganz...
    Warum das mit dem Hardware-USART nicht besser geht, auf den würd ich nur sehr ungern verzichten.

    Hat jetzt für mich nicht die höchste Prio, mal sehen, erstmal steht ATX-Support im Vordergrund, und da sieht es schon ganz gut aus 8)
    Wer die Ironie findet, darf sie behalten ^^
  • kbr schrieb:

    Hat jetzt für mich nicht die höchste Prio, mal sehen, erstmal steht ATX-Support im Vordergrund, und da sieht es schon ganz gut aus 8)
    Das hat ganz und gar keine hohe Priorität. Fühl Dich da bitte nicht von mir gedrängt oder so. Ich schlage nur vor und trage Informationen zusammen. Was wir (vielmehr Du) daraus machen (können), ist eine ganz andere Sache.
    Das sdrive-max ist für mich bereits so wie es jetzt ist fertig und toll und alles was da noch künftig dazukommen mag, sind Features.
  • Neu

    Beim letzten Treffen haben wir das SDrive-Max intensiv getestet, Top :thumbsup: :atari: Hardware .
    Eine Bitte hätten wir zur Option "NEW".
    Single und Medium Desinty Atr-Files werden problemlos erstellt, über 100mal ausprobiert. :ilikeit:
    Wäre es möglich auch größere ATR-Dateien mit einzubinden? :sabber:
    Hier einige Infos dazu. Ab DD wird der Percom Block für die Formatierung gesetzt -> Übersicht der Befehle (siehe Percom $4E).
    Im AtariWiki gibt es ein Diagnoseprogramm mit dem man Disketten formatieren oder ihren Medium Status abfragen kann.

    Wir würden uns über eine Erweiterung sehr freuen. :tanz:

    Viele Grüße,
    Flash
    Bilder
    • 2 Sdrive-Max.jpg

      92,92 kB, 1.000×750, 15 mal angesehen
  • Neu

    Ja, das steht eigentlich auch schon länger auf meiner TODO-Liste...

    Jetzt hab ich erstmal ein paar nervige, kleine Bugs beseitigt, die mich schon länger verfolgt haben, aber sonst vermutlich keiner gemerkt hat :whistling: , bevor sich das weiterzieht. Ein paar interne Optimierungen, um etwas Speicher zu sparen, und @Farb hat den ATX Basis Support eingebaut. Viel mehr wirds vermutlich für die V05 nicht mehr werden, ich mach jetzt lieber kleinere Schritte, fördert die Übersicht, vorallem wenn man jetzt zu mehrt dran arbeitet.
    Wer die Ironie findet, darf sie behalten ^^
  • Neu

    kbr schrieb:

    Ja, das steht eigentlich auch schon länger auf meiner TODO-Liste...

    Jetzt hab ich erstmal ein paar nervige, kleine Bugs beseitigt, die mich schon länger verfolgt haben, aber sonst vermutlich keiner gemerkt hat :whistling: , bevor sich das weiterzieht. Ein paar interne Optimierungen, um etwas Speicher zu sparen, und @Farb hat den ATX Basis Support eingebaut. Viel mehr wirds vermutlich für die V05 nicht mehr werden, ich mach jetzt lieber kleinere Schritte, fördert die Übersicht, vorallem wenn man jetzt zu mehrt dran arbeitet.
    Bislang habe ich noch keine Erfahrung mit dem ATX Format und freue mich schon auf das Testen.
    Es gibt immer mehr Atari User die das Interface haben wollen. Zuerst kam die Antwort, so etwas haben wir schon.
    Zeigt man aber die Funktionen und gibt den Hinweis zum Gesamtpreis für das Display inklusive Uno, ist das Interesse an einem Nachbau geweckt.
    Der Kreis der Besitzer wird immer größer.

    Ein großes Dankeschön :thnks: an beide Entwickler von uns. :thanx:
  • Neu

    V0.5 wurde soeben released: kbrnet.de/projekte/sdrive-max/index.html


    Wesentliche Änderungen:
    • unterstützung von CAS-Files im raw binary format, keine mit FUJI-Header!
    • ATX-Support
    • einige Optimierungen und Bugfixes


    Ich möchte mich an dieser Stelle auch nochmal herzlich für die durchwegs positiven Rückmeldungen bedanken, das gibt auf jeden Fall Ansporn weiter zu machen :thnks:
    Wer die Ironie findet, darf sie behalten ^^
  • Neu

    Ich wollte auf die neue Version flashen. Aber was aus dem Archiv nehme ich für meinen Atmega 328P? :gruebel

    atmega328-hx8347g
    atmega328-ili9329
    atmega328-ili9341

    Habe ich zur Auswahl. Mein meinem Chip kann ich aber nur 328P lesen.
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von oobdoo ()

  • Neu

    CapFuture1975 schrieb:

    Die letzten Buchstaben und Zahlen geben das Display an! Wenn Du das "gute" Display von Amazon hast, dann ist atmega328-ili9341 dein Freund.
    Jo, das hat geklappt. Danke.

    Aber irgend etwas ist immer. :cry:

    Hab ja noch einen zweiten Arduino mit weiterem Display. Alles noch ganz frisch. Da läuft die Batchdatei nicht mehr. Egal ob mit oder ohne Display.

    avrdude: ser_open(): can't open device "\\.\COM4": Das System kann die angegebene Datei nicht finden.

    Das Display bleibt durchgehen weiß, wenn ich den USB anstecke.

    Nachtrag:
    Jetzt spinnt irgend etwas mit dem USB. Mein Cardreader will aktuell auch nicht (mehr) gefunden werden. Mal Rechner neu starten werden... ||
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von oobdoo ()

  • Neu

    oobdoo schrieb:

    CapFuture1975 schrieb:

    Die letzten Buchstaben und Zahlen geben das Display an! Wenn Du das "gute" Display von Amazon hast, dann ist atmega328-ili9341 dein Freund.
    Jo, das hat geklappt. Danke.
    Aber irgend etwas ist immer. :cry:

    Hab ja noch einen zweiten Arduino mit weiterem Display. Alles noch ganz frisch. Da läuft die Batchdatei nicht mehr. Egal ob mit oder ohne Display.

    avrdude: ser_open(): can't open device "\\.\COM4": Das System kann die angegebene Datei nicht finden.

    Das Display bleibt durchgehen weiß, wenn ich den USB anstecke.
    Auch wenn die Adruino UNO alle gleich aussehen, sie sind es vom Treiber her nicht. Ich habe 6 Boards bei der jeder einen anderen COM-Port installiert hat.
    Wenn du Windows benutzt, dann schau mal unter dem Gerätemanager nach, welcher COM Port aktiv ist.
    Ein anderer Weg ist die Arduino Software. Unter Werkzeuge - Port wird bei eingestecktem UNO auch der COM Port angezeigt.
    Das weiße Display ist beim ersten Einschalten normal, es ist nicht defekt.

    Ein Dankeschön an Daniel :wilkommen: und Klaus für die neue Erweiterung :thnks:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Flash ()

  • Neu

    Flash schrieb:


    Auch wenn die Adruino UNO alle gleich aussehen, sie sind es vom Treiber her nicht.
    Danke genau das war das Problem. :thanx:

    Irgend etwas ist heute beim USB etwas bockig. Mein Cardreader wollte ja auch nicht mehr funktionieren.
    Erst als ich den im Schreibtisch verbauten 4-fach USB-Verteiler komplett abgezogen und neu eingesteckt hatte, tauchte der Cardreader wieder auf. :huh:
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power