SD card am Paralellport, MS-DOS

    > BYTE n, d;

    >

    > n=10;

    > do

    > {

    > rcvr_mmc(&d, 1);

    > }

    > while ((d & 0x80) && (--n)); <-- Warning Possibly incorrect assignment in function xxx

    >

    > Wie funktioniert das Abbruch Kriterium, und warum meckert der Compiler.


    Wie schon Funkenzupfer geschrieben hat, wird 'd' dann Null, wenn das höchstwertigste Bit nicht gesetzt ist, die UND Relation zwischen dem Testen von 'd' und dem Wert von 'n', der durch das Herunterzählen auf 0 irgendwann steht, trägt dazu auch bei.

    D.h. also, das Codefragment versucht 10x etwas zu empfangen, und bricht früher ab, falls der gelieferte Wert in 'd' dem ersten Kriterium (Bit gesetzt) entspricht.


    Finde den C Code nicht überwältigend transparent geschrieben, das geht auch besser.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Kein Stress wegen des C-Codes.
    Ich wollt halt gestern Abend das Warning weg haben, weil der Editor bei jedem Compile immer genau dort gelandet ist. Warning ist noch immer da, wie der Code da jetzt genau funktioniert ist mir eigentlich egal, ich möchte ihn aber auch nicht kaputt machen.
    Womöglich frag eine C Korifäe hier in der Firma (nix homeoffice).


    mfG. Klaus Loy

    Zitat von 1ST1
    Zitat von Toshi

    Gibts überhaupt "unidirektionale" = nur in eine Richtung funktionierende parallele Schnittstelle?

    Ja, die einfachen parallelen Schnittstellen an den ersten XTs, auch meine Olivetti M24 ist davon "betroffen". EPP und ECP kamen erst später.

    An sich sind alle parallellen Schnittstellen zu einem gewissen Maß bidirektional. Die originale Spezifikation sieht ein paar Eingänge vor (z.B. ACK, BUSY, Paper End), mit denen der Drucker begrenzte Rückmeldungen an den Computer geben kann. Diese Eingänge kann jede parallele Druckerschnittstelle natürlich auch für bi-direktionale Übertragung nutzen.


    Da eine SD-Karte sowieso nur 4 Leitungen (2 rein, 2 raus) zur Datenübertragung braucht, reicht das lässig.

    Klar reicht das für SD-Card

    Wenns dann mal (bei mir funktioniert), möchte ich sowas auch an den Atari ST auch an den Druckerport ran machen, um Files hin und her zu transferieren.


    Aber der Begriff bidirektional würde besser passen wenn die Daten "symetrisch" hin und her fließen könnten, wie z.B. bei SCSI oder IEEE-488 wo halt die acht Datenleitungen von senden auf empfangen umgeschaltet werden, wie bei einem Datenbus. Und dann brauchst natürlich nocht passende Steuerleitungen.
    Aber damals war der LPT halt nur für einen simplen Centronix Drucker für Daten --> Drucker (unidirektional, Steuersignale nicht mit betrachtet.


    mfG. Klaus Loy

    • Offizieller Beitrag
    Zitat von klaly

    Ich wollt halt gestern Abend das Warning weg haben

    Dann schreib das mal so:


    Code
    do
{
  rcvr_mmc(&d, 1);
  --n;
}
while ((d & 0x80) != 0 && n != 0);

    Da sollte nichts zu meckern ueberig bleiben.

    Zitat von klaly

    Wenns dann mal (bei mir funktioniert), möchte ich sowas auch an den Atari ST auch an den Druckerport ran machen, um Files hin und her zu transferieren.

    Das würde mir auch gefallen!!! :thumbup::thumbup::thumbup::thumbup:


    Allerdings wird das schwierig, denn da hast du nur eine Rückleitung: Busy


    Siehe https://info-coach.fr/atari/ha…faces.php#if_parallel_con


    Einfacher ist wahrscheinlich ein Rom-Port-Adapter. Ja, auch auf dem kann man trickreich schreiben...

    1ST1

    • Offizieller Beitrag

    ...und wenn dann alles schön funktioniert, freue ich mich schon auf einen Artikel für die LOAD#7 ;)

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

    Gefällt mir 2

    Darf man fragen, was ihr mit der SD-Karte am LPT machen wollt?

    Die ist, sagen wir mal optimistisch, sehr behäbig, da ist jedes Zipdrive eine Rakete dagegen.

    Zitat von dr.zeissler

    da ist jedes Zipdrive eine Rakete dagegen.

    Kommt auf den Parallelport an. An einfachen Parallelports kann das Zip-Laufwerk auch kaum mehr Leitungen nutzen, um Daten an den PC zu schicken, also auch nicht oder nur geringfügig schneller. Die SD-Karten sind billig, jeder hat wahrscheinlich noch kleine funktionierende Karten rumliegen, und ZIP-LW halten auch nicht ewig.

    1ST1

    @dr.zeissler, was ich damit machen will:

    Ich möchte damit Files auf einen DOS Notebook bringen können.
    Ganz konkret für meinen PCD-4ND bei dem ja noch immer das Floppy defekt ist (Riemen). Das Netwerk, 3Com PCMCIA hab ich auch noch nicht eingerichtet.


    Dann hab ich das Projekt mit der SD am Parallelport gefunden und wollte das am Sonntag mal schnell aufbauen. Mit dem Ergebnis dass gar nichst ging :(


    Und nun ist es ein "Forschungs Projekt" geworten.

    In der Mittagspause hab ich zwei schöne Links zum Thema SD-Card gefunden, die möchte ich hier rein pinnen, damit ich sie auch wieder finde:


    microcontroller.net, MMC- und SD-Karten


    elm-chan.org, How to Use MMC/SDC


    mfG. Klaus Loy

    Wenn auf dem Rechner Dos installiert ist nimm interlink/interserv und ein laplink-kabel.

    https://www.youtube.com/watch?v=AbkomKU0wUE

    Klar interlink und intersvr hatte ich letzhin auf wieder mal benutzt. Das ist eigentlich relativ flott, es überträgt ja die Daten in 4Bit Packeten über den Parallelport. Und vor allem du brauchst einen zweiten DOS Rechner.


    mfG. Klaus Loy

    Zitat von dr.zeissler

    Wenn auf dem Rechner Dos installiert ist nimm interlink/interserv und ein laplink-kabel.

    https://www.youtube.com/watch?v=AbkomKU0wUE

    Spielverderber :ätsch:

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    An die Person, die meine Schuhe versteckt hat, während ich auf der Hüpfburg war: Werd' erwachsen! :motz:


    ::matrix::

    Gefällt mir 1

    Hallo Freunde,

    mein forschen hat mich ein Stückchen weiter gebracht:

    1. Mein Testprogramm SD.EXE kann die SD initialisieren und erkennen und
      findet in der Function check_fs() den Magic 0xAA55 und den "FAT" String.
      D.h. das Programm kann erfolgreich Sektor 1 lesen und findet die Magik Daten.
    2. Ich kann erfolgreich den Treiber compilieren und printfs einbauen.
      Der Treiber beendet die function disk_initialize() angeblich mit Succes,
      danach kommt check_fs() dran, leider kann diese Funktion keinen Sektor lesen.
      Ursache bisher unklar. Vermutlich hat disk_initialize() doch nicht richtig funktioniert.

    Es geht voran, aber langsam.


    mfG. Klaus Loy

    Leute all das will ich doch gar nicht.
    Ich möchte einfach diesen SD-Card Aufbau zum Laufen bringen, weil ich cool finde.


    mfG. Klaus Loy

    Hast du mal 'ne andere SD-Karte versucht? Manche sind da ein bißchen zickig im SPI-Mode.


    Tobias

    Kurzer Feierabend Bericht:

    Da waren einige Sackgassen mit meinem Debug Code.


    Nun hab ich den Treiber SD.SYS und mein SDTEST.EXE nur minimal mit Debug Ausgaben bestückt.
    Beide Ausgaben und Salea Logik Analyser wurden verglichen.
    Beides war gleich bis nach disk_initialize()
    Danach soll der erste Sector gelesen werden, für check_fs(), Partition prüfen ...
    SDTEST.EXE liest erfolgreich diesen Sector, SD.SYS liest von einem unsinnigen Sector und bekommt error.

    Die Codestelle konnte eingegrenzt werden:


    /*-----------------------------------------------------------------------*/

    /* Read Sector(s) */

    /*-----------------------------------------------------------------------*/

    DRESULT disk_read (BYTE drv, BYTE DOSFAR *buff, DWORD sector, UINT count)

    {

    DRESULT dr = disk_result(drv);

    if (dr != RES_OK) return dr;

    cdprintf("\ndisk_read...\n");

    cdprintf("\nsect: "); outlhex (sector); cdprintf("\n"); <---- hier ist sector noch 0 d.h. sinnvoll


    if (!(CardType & CT_BLOCK)) sector = DWORDLSHIFT(sector,9); /* Convert LBA to byte address if needed */


    cdprintf("\nsect: "); outlhex (sector); cdprintf("\n"); <---- hier hat sector einen unsinnigen Inhalt


    D.h. ich muss mal schaun was die Zeile dazwischen macht, DWORDLSHIFT ist ein Macro mit bedingter compilierung, ...


    mfG. Klaus Loy

    Ersetze mal den ganzen Makroaufruf durch


    Code
    if (!(CardType & CT_BLOCK)) 
   sector *= 512; /* Convert LBA to byte address if needed */

    Das solte eigentlich genau dasselbe machen (Wenn die Karte nicht mit Blockaddressierung arbeitet, sondern mit Byteadressierung (das wäre eher ungewöhnlich), wird die Blocknummer einfach mit 512 Bytes/Sektor multipliziert.).


    Sollte es das nicht sein, solltest du mal schauen, ob die Adressierungsart richtig erkannt wird. SDHC und SDXC - also alle modernen - benutzen alle LBA-Addressierung. Nur die alten MMC-Karten verwenden tatsächlich Byte-Adressierung, bei denen würde die Zeile überhaupt ausgeführt.


    Also vielleicht im Zweifel doch mal 'ne andere Karte probieren.


    Tobias

    Guten Morgen tofro,
    danke für den Tip, ich werd mir das heute nach Feierabend mal in ruhe anschaueb und auch deinen Tip mal ausprobieren.


    Ich bin ja schon froh, dass ich das so erstmal als Unterschied sah. Vermutlich soll da zuvor ein Kartentyp und evtl. ein Modus erkannt werden, evtl. geht da was schief. Aber es schien, das die zuvor ermittelten Werte im testprogramm und treiber gleich waren, was ich anhand der SALEA Aufzeichnung sah.

    Mal schaun.


    mfG. Klaus Loy

    Aber 0 kann man beliebig LeftShiften oder mit Zahlen multiplizieren, das bleibt 0!

    Stimmt denn der Aufrub von outlhex. Was tut das genau? Erwartet das vielleicht einen anderen Datentyp?

    Das Genie beherrscht das Chaos

    @ChaosRom,
    ja 0 << x egal sollte 0 bleiben.
    Aber mir kommt ja irgendwie quatsch raus.
    Mal schaun ich gleich wieder ran.

    Jetzt hab ich ganz naiv mal diese DWORDLSHIFT Funktion auskommentiert und schon ließt mein Treiber den ersten Sektor. Es kommen auch sinnvolle Daten.
    Zum einen brauch es diese DWORDLSHIFT Funktion, weil der Offset mal als Sektor bzw. logische Block Nummer und mal als Byteoffset übergeben wird. Dies ist wohl vom SD-Card Typ, bzw. der Größe abhängig. Warum es bei mir schief läuft und wirklich Quatsch raus kommt, das weiß ich noch nicht.

    Ich beim letzten Compiler Lauf hab ich das Modul SDMM.C mal mit Assembler Listing übersetzt, wer will kann sich das mal ansehen. Files kommen gleich im Anhang mit dazu. Der Original Treiber ist weiter oben mit Quellen verlinkt.



    mfG. Klaus Loy

    ... dann hab ich heute Morgen mein MicroSd nochmal neu formatiert.
    Mit dem oben von tokabln empfohlenen SD-Formatter.

    https://www.sdcard.org/downloads/formatter/


    ... und schon sahen meine Debug Ausgaben besser aus. Zuvor wollte der Treiber irgendwie Infos aus der Partition Tabelle holen, welche entweder unsinnig war oder als unsinnig interpretiert wurde. Auf alle Fälle hieß es dann
    "SD initialized on DOS drive D"


    Jetzt schien es zu gehen DIR D: dann kammen unglaublich viele meiner Debug Ausgaben.
    Dann hab ich die zum größten Teil wieder angeschaltet, schon sah es besser aus:

    entschuldigt das schräge Foto, aber das Display spiel recht stark.

    Nun dachte ich, bin ich blöd, lag es nur an der Karten Formatierung. Nein,denn der Originaltreiber geht nach wie vor nicht. Hauptproblem ist scheinbar die kommisch 32Bit ShiftLeft Funktion, die völligen Unsinn macht.
    Beim Einkreisen der Probleme ist mir der Treiber manchmal voll angestürzt mit PC Reboot.
    Ursache hierfür war der etwas knappe Stack von orginal nur 256Byte, den hab ich temporär verdoppelt. So konnte ich dann schön debugen.

    Aktuell hab ich eine nicht befriedigende 32Bit ShiftLeft Funktion gemacht. Die kann im Moment nur fix um 5 und um 4 Bit nach links schieben. In Summe sind das dann die gewünschten 9Bit, dummerweise wir in der IO_CNTRL Funktion ein Shift um n Bit benötigt. Das ist erstmal abgeklemmt.


    Ich kann nun mit dem modifizierten Treiber das Direktory anzeigen und ein TestFile ausgeben :)


    mfG. Klaus Loy

    Es gäbe da zwei aktuell offene Fragen:

    1. ich bräuchte einen 16Bit Compiler tauglichen Algorithmus bzw. C-Code für shiftleft(UInt32 val, int n) das ist wohl nicht so trivial.

    2. Mit welchem modernen Compiler kann 8086 Code erzeugen und dann noch für DOS. EXE-Header, Driver.SYS Format.


    Falls jemand Antworten hierzu hat, bitte her damit.


    Aktuell compiliere ich mit dem Borland_C Compiler BC45, der in einer WinXP VMWare läuft.
    Es geht, aber nur eingeschränkt. Dieser Komplier kann scheinbar kein 32Bit SHL bzw. ich kann die zugehörig Lib nicht einbinden. Überhaupt verwendet der Treiber vermutlich gar keine Lib, er soll ja klein sein.
    Der ersteller des Original Treiber hatte da wohl auch Probleme, siehe in dem File SDMM.C


    Mein aktueller Code:
    Original dwordlshift(DWORD d, int n) bei Zeile 150


    Meine "Lösung" void sld_5(unsigned long *val) bei Zeile 605, dies war nur zum Test, aber es geht. Shiftweite fix codiert, max 8Bit


    mfG. Klaus Loy

    Versuche es mal mit dem Watcom C/C++ Compiler bzw. dem Open Watcom C Compiler. Der war bzw. ist immerhin "C99" Standard kompatibel.

    Welche Version es nicht mehr schafft, puren 8086 Code zu erzeugen, weiss ich nicht mehr. Genügend verschiedene Versionen (eben halt auch ältere) gibt es aber immer noch zum Herunterladen.

    Auf

    https://sourceforge.net/projects/openwatcom/

    https://github.com/open-watcom

    findest Du die Open Watcom Compiler.

    Auf https://winworldpc.com/product/watcom-c-c/100 eventuell auch passende ältere Versionen.


    Mit Gnu C wirst Du nicht weit kommen.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Hi Peter,
    ich dachte wirklich an einen Modernen Compiler, weil nicht jeder hat einen alten Borland_C
    Das war bei mir Zufall und im MakeFile stand bcc und tasm, genau das Borland_C und Turbo_ASM Zeug.
    Danke für den Tip, aber aktuell hab ich keine Lust den Watcom zu nehmen.

    Aber ich kann die Sachen ja mal runter laden.


    mfG. Klaus Loy