Posts by kbr

    Also ich werde das höchstwahrscheinlich nicht machen, da mir zum Einen die Abmessungen vom Mega nicht gefallen, der ist ca. 1,5x größer als der UNO, und zum Anderen ist das PIN-Layout komplett anders, da würde glaub nicht mal die SD-Karte funktionieren, weil die Pins dort anders belegt sind. Zudem hab ich mir von vorn herein als Ziel gesetzt, es muß in einen UNO passen, und dabei bleib ich!


    EDIT: Wenn dann gleich AMD Cortex :bgdev

    Da gäbe es schon noch ein paar Dinge, z. B. gibt es immer noch einen Pufferkonflikt, wenn der Filebrowser geöffnet ist, und dann der Atari etwas lädt, eventuelle Fehler bei SD-Zugriffen werden nicht abgefangen, Erstellen von DD-Images, einen Highspeed Loader, usw.


    Große Erweiterungen sind jedoch nicht mehr drin, wir sind schon ziemlich am Ende vom Flash, z. B. wollte jemand PC-Link Support, da seh ich schwarz, oder es müsste etwas anderes dafür rausfliegen.


    Und dann könnte man sicher noch das ein oder andere an der Grafik verbessern...

    Hast recht, das war ein ziemlich unüberlegter quick & dirty hack, als ich festgestellt habe, daß ich hier ja 8 Bytes weiter schiften muß, anstatt 4, aber selbst bei 4 lohnt es sich auch noch über add zu gehen. Habs angepasst.


    EDIT: Mir war auch nicht bewusst, daß ein INC IX so teuer ist, selbst ein INC HL braucht nur 6 Zyklen...

    Image von Disc erstellen geht inzwischen auch einigermaßen, solange es sich um halbwegs standard Formate handelt. Das dauert ein kleinwenig länger als das Schreiben, denn hier ist etwas mehr Aufwand notwendig, zuerst neue Datei erstellen, FAT allozieren, die Sector-ID's auslesen, und dann beim Schreiben auf SD muß eine CRC berechnet werden. Habs jetzt noch nicht gemessen, aber ca. 6 Minuten schätze ich.


    Ich werd demnächst mal eine erste Beta als Binary bereitstellen, da der Build doch nicht so ganz einfach ist, und man ein paar spezielle Tools braucht, um den AMSDOS Header zu erstellen, usw. Und dann mal sehen, wie die Resonanz so ist, bevor ich mich groß in weitere Schritte stürze. Zudem ist dann Sommer, und da haben andere Hobbies Vorrang ;)

    Hi,


    ich mach hier mal einen neuen Thread auf, in dem es nur noch um die Entwicklung des sdrive4cpc geht. Der Name ist vielleicht noch nicht gerade das, was es im Moment kann, aber es kann ja noch werden, und mir ist auf die Schnelle auch nix besseres eingefallen. Zudem stammt ja vieles auch vom SDrive.


    Die Idee war eine einfache, günstige Lösung zu haben, um Daten zwischen CPC und anderen Rechnern auszutauschen. So hab ich mich dran gemacht, eine SD-Karte direkt mit dem Parallelport am CPC zu verbinden über einfache Pegelwandler mit Widerständen und einem Transistor für den Eingang. Alles weitere läuft dann per Software, SPI, MMC, FAT, usw. Dabei hab ich mich natürlich am Code vom SDrive vom Atari bedient.


    Im Moment kann man zumindest schon mal DSK-Images von der SD-Karte zurück auf echte Disc schreiben, und andersrum, jedoch noch sehr experimental. Der momentane Stand der Sourcen liegt auch schon auf github: https://github.com/kbr-net/sdrive4cpc


    Vielleicht finden sich ja noch 1-2 erfahrene CPC-User, die sich an der Entwicklung beteiligen möchten, da zum Einen meine Erfahrung mit CPC und Z80 quasi erst kürzlich begonnen hat, und ich zum Anderen auch nicht so viel Freizeit, sowie auch noch andere Projekte habe.


    So long.


    Klaus

    Ich konnte inzwischen durch rewrite der SPI-Funktion in Assembler die Lesegeschwindigkeit von SD gut verdoppeln, ein Image mit 40 Tracks wird jetzt in 4:33 Minuten geschrieben, viel mehr wird nicht mehr drin sein.


    Erzeugen von Images geht auch schon fast...

    Ah ok, du hast dann also einen "Treiber" für den CPC geschrieben. Ist der denn dann auch performant genug?
    Und einiges an Speicher frisst der sicherlich auch.

    Naja "Treiber" ist für mich etwas, was sich zwischen Hardware und Betriebssystem befindet, und dann die Standardbefehle vom System benutzt werden können. Das kann es vielleicht auch noch werden, aber im Moment ist es nur ein eigenständiges Programm.


    Performant ist relativ, es ist im Moment ca. 2,5x schneller als von Tape, was will man von den 4MHz erwarten, wenn man jedes Bit einzeln über die Leitung schaufeln muß, aber da versuche ich auch noch etwas zu optimieren.


    Das mit der Größe hatte ich ja bereits erwähnt, im Moment belegt der Code ca. 16K, Tendenz steigend.

    @kbr,
    ich habe noch nicht so ganz verstanden wie Deine Lösung funktioniert?
    Kannst du das vielleicht etwas genauer erklären?
    Das wäre super.


    Also ich schließe eine SD-Karte direkt über einen einfachen Pegelwandler für 3.3V am Parallelport des CPC an, und lese diese dann direkt per Software am CPC aus. Der Hardwareaufwand ist also minimal, und ich hab doch eine recht komfortable Möglichkeit, Daten zu übertragen.
    Im Moment kann ich halt erstmal nur grundsätzlich die SD-Karte initialisieren, und das Verzeichnis auslesen. DSK auf echte Disc schreiben geht aber auch schon fast, da hab ich einfach zum Großteil den Code von DSK2DISC übernommen. Geplant ist das Ganze auch noch in andere Richtung, also von echter Disc ein Image erzeugen, und auf SD-Karte speichern.


    Und dann mal sehen, was mir noch so einfällt, Programme direkt von SD-Karte starten, oder Images mounten wäre natürlich auch cool, aber das wird aufgrund des großen Speicherbedarfs für das Hauptprogramm schwierig werden, denn es muß ja das komplette FAT-Dateisystem alles in Software gemacht werden.


    Bei Gelegenheit erstell ich mal einen Schaltplan, etwas Doku, und werd das dann auch auf github veröffentlichen.

    Warum nicht, mit FPGA hatte ich bislang jedoch noch nichts zu tun:
    Aber erstmal möchte ich das hier noch zu was halbwegs Vernünftigem bringen, daß man zumindest mal DSK-Images auf echte Disk schreiben kann, und vielleicht auch andersrum.

    Interessanterweise kann ich damit eine alte SD-Karte ohne Probleme auslesen, welche am PC nicht mehr funktioniert. Das ist vermutlich der langsamem Taktung geschuldet, die Karte macht wohl die sonst übliche Taktung nicht mehr mit. Könnte man ja schon fast als Recovery Lösung bezeichnen ;)

    Mir schwebt da eine Billiglösung am Parallelport vor, es sollte doch kein Problem sein, dort SPI zu simulieren, müsste dann halt alles per Software passieren, mal sehen, so langsam finde ich Gefallen an der Kiste.

    gesagt, getan, funzt :thumbup:


    Eben mal die FAT-Library und den MMC-Code vom SDrive portiert, und eine SPI-Library für den Parallelport erstellt. Bislang noch keine wirkliche Funktion, aber mir ging es erstmal ums Prinzip. Jetzt kann man weitersehen...


    Hab ich gesehen, aber irgendwie kann ich keinen Preis dazu finden, ist bestimmt auch nicht billig...


    Mir schwebt da eine Billiglösung am Parallelport vor, es sollte doch kein Problem sein, dort SPI zu simulieren, müsste dann halt alles per Software passieren, mal sehen, so langsam finde ich Gefallen an der Kiste.

    Ich versteh nur Bahnhof...


    1. Ich schreibe am PC unter Linux mit dem Tool 2CDT ein Disc Image als Datei in ein Tape Image. DISC.DSK -> DISC.CDT
    2. Ich wandle das Tape Image mit dem Java-Tool CDT2WAV in eine WAV-Datei. DISC.CDT -> DISC.WAV
    3. Jetzt lade ich mein Programm am CPC, welches nun Daten über den Tape-Port einliest, und gleichzeitig starte ich die Audiowiedergabe der WAV-Datei am PC, welchen ich über ein Audio-Kabel mit dem Tape-Port am CPC verbunden habe.
    4. Nachdem alle Daten für den 1. Track geladen sind, halte ich die Wiedergabe an, denn jetzt beginnt mein Programm den Track auf der Disc im CPC mit den entsprechenden Sector-Headern aus dem DSK-Image zu formatieren, und anschließend kopiert es die Sector-Daten in die Sectoren. Das dauert ca. 3 Sekunden.
    5. Danach wird wieder weiter von Tape geladen für den nächsten Track, ich starte also die Audio-Wiedergabe wieder, usw.


    Vielleicht etwas mühsam, aber funktioniert, dauert ca. 25 Min., und so oft werd ich das jetzt nicht brauchen...

    Aja, trotzdem zu teuer. Gibts sonst keine andere SD-Lösung für die Kiste am Parallel- oder CPU-Port?


    In Sachen Assembler hab ich mal etwas mit dem MAXAM experimentiert, aber das ist auch nicht so ganz das Wahre. Bin dann doch erstmal über einen Cross-Assembler PASMO gegangen, der erzeugt wenigstens gleich den passenden Fileheader mit. Und damit hab ich es immerhin schon zu einem kleinen Programm geschafft, womit ich DSK-Images über den Tape-Port via Soundkarte zurück auf Disc schreiben kann 8)

    Den Effekt kenn ich, wenn keine Floppy dran hängt, danach sucht er dann vergebens, und kommt nicht weiter, oder es dauert sehr lange(1 Minute oder so).


    EDIT: Du hast diese speziellen 16bit EPROM's eben mal schnell zur Hand? :respect: