Hello, Guest the thread was viewed22k times and contains 163 replies

last post from freak64DTV at the

Bausätze MMC2IEC 2008, Part1

  • Okay, auch ohne einen echten Plan in der Richtung habe ich inzwischen Anfragen für 12 Bausätze mit der Platine 1.9 bekommen.


    Übrigens am Ende dieses Threads zu sehen: Hardware 1.7 + Hardware 1.8


    Wird also vielleicht langsam Zeit, zumindest mal den Bedarf zu ermitteln.


    Wobei ich gerade noch ein Problem mit der 1.9 festgestellt habe.
    Beim Einlegen der SD-Karte macht der Mega32 einen Reset, was genau passiert muss ich noch nachmessen.
    Auf jeden Fall schlägt die Brown-Out-Erkennung zu denn wenn ich die BOD per Fuse deaktiviere,
    dann macht der Mega32 keinen Reset.
    Das kann nur bedeuten, dass die Spannung am AVR knapp unter 2,7V fällt.
    In den Griff bekommen müsste man das eigentlich indem man einfach die Kondensatoren am Spannungs-Regler ein wenig grösser macht.
    Andererseits ist das fast sowas wie ein Feature da durch den Reset auch der Bootloader anspringt und man garnicht erst ausschalten muss sondern einfach die Karte mit der neuen Software einlegen kann.
    Aber nur fast ein Feature da es eben ein unkontrollierter Neben-Effekt ist der sich von Karte zu Karte unterscheiden kann -> könnte ja auch einen Reset geben, wenn man auf eine stromhungrige Karte schreibt.


    Okay, genug Technik.


    Die ersten Bausätze der 1.8'er und 1.9'er Platinen habe ich für 15 Euro abgegeben, da sind 10,50 für die Bauteile
    und 4,50 für die Platine enthalten.
    Dabei habe ich hoffentlich keinen Verlust gemacht, das Porto für die Beschaffung der Teile wollte ich dann nicht haarklein mit reinrechnen.
    Wobei die Teile im wesentlichen durch die kleineren Mengen teurer waren, der Mega32 und der SD-Sockel haben zusammen 1,50 mehr gekostet als bei der 1.6'er Sammel-Bestellung.


    Also 15 Euro sind erstmal die Basis von der aus nach unten korrigiert wird, wobei das wesentliche Problem die Platinen sind, da müssen erstmal genug zusammenkommen.
    Allerdings will ich auch mal anfragen, was es kostet, die Controller gleich bestücken zu lassen, nochmal über 60 Stück von den Dingern aufzulöten hatte ich eigentlich nicht vor, das wird auf Dauer langweilig. ;)
    Vielleicht kann die sogar gleich programmiert kaufen, ich weiss aber nicht, ob die Firma die mir da vorschwebt überhaupt an privat und vor allem deutlich unter 1000 Stück liefert...


    Oh ja, dazu kommt noch das Porto und der Karton.
    Wobei ich dann mal schaue, dass ich diesmal kleinere Kartons bekomme.


    Je nach Anzahl bewegen wir uns also zwischen 20 Euro und 10 Euro.
    Wobei 10 Euro erst erreicht werden, wenn es wirklich unangenehm viele werden.



    Vorteile der neuen Version gegenüber der 1.6:


    - weniger Teile
    - grössere Teile mit zusätzlich vergrösserten Footprints
    - Quarz für Fastloader Unterstützung
    - Versorgungs-Spannungs-Bereich jetzt 4,5V...10V da der Controller mit am Spannungs-Regler hängt
    - Anschluss für TXD und GND extra um Debug-Informationen abzugreifen


    Nachteile:


    - auch auf der Unterseite sind jetzt ein paar Flache Bauteile, 2 x 56pF in 1206, 4 x 4k7 in 1206
    - die Teile sind zum Teil teurer, statt zwei FET's zu je 9 Cent sind es drei FET's zu je 35 Cent


    Leider bekommt man nicht alle Komponenten bei CSD - muss ich mal anfragen.
    Bei Reichelt zu bestellen ist nicht so witzig weil die ja kaum Mengen-Nachlass haben.
    Ab 297,50 Euro 3 Prozent Nachlass bringen es einfach nicht.



    Also nochmal, das geht nicht sofort los, auch nächste Woche noch nicht, Ziel ist es erstmal für mich abzuklopfen,
    in welchem Rahmen sich der Bedarf hier im Forum so bewegt um dann zu sehen, welche Optionen sich daraus ergeben.

  • Wie interessant wäre das eigentlich, den Mega644V-10AU statt des Mega32L-8AU einzusetzen?


    Okay, der hat doppelt so viel Speicher - aber ob das wirklich gebraucht wird ist ja noch nicht raus.
    Und der kostet auch gleich das doppelte, für weniger als 6,80 Euro habe ich den noch nicht gesehen.


    Bricht dann ja auch mit der Kompatibilität zu den 1.6'er Platinen von denen es reichlich gibt.



    Als Kandidat für eine potenzielle 2.0 hatte ich ja den Mega328P ins Auge gefasst.
    Aber eigentlich ist das Quatsch. Der wesentliche Vorteil den das Ding bietet ist, dass er weniger Pins hat.
    Bei näherer Betrachtung ist das nicht so der Bringer.


    Okay, für einen Lochraster-Aufbau mit einem DIL28 statt des DIL40 wäre das prima, meine Platine bekomme ich
    aber eher nicht deutlich kleiner mit dem Ding - wofür auch, meine Platine ist sowieso schon die kleinste zur Zeit.


    Wann der Mega328P im Handel auftaucht weiss wahrscheinlich nicht mal Atmel zur Zeit.
    Und günstiger wird der wohl auch kaum werden.



    Als Kandidat für eine potenzielle 3.0 kämen möglicherweise die ATXMega in Betracht.
    Die sind aber noch nicht einmal offiziell von Atmel angekündigt und auch für die gilt, dass man erstmal einen richtig guten Grund finden müsste, damit sich der Umstieg lohnt.


    Okay, die Dinger haben vielleicht mehr Speicher, nett.
    Die SMD-Gehäuse werden kleinere Pin-Abstände bekommen - also schwieriger zu löten sein.
    Bis 32 MHz bei 2,7...3,6V - brauchen wir nach derzeitigem Stand nicht.
    DMA-Controller und Multi-Level-IRQ - auch nett, nützt nur nichts, wenn der Controller fast nur schläft.



    Ich werde mir lieber mal die Schaltung für das Display-Modul näher ansehen.


    Hier mal ein Bild von meinem DTV zur Zeit:


    IMG_0174s.jpg


    Hier man kann man ganz gut erkennen wie einfach es ist, mehrere mmc2iec gleichzeitig zu verwenden,
    ich habe einfach drei MikroMatch Stecker auf das Flachbandkabel gesetzt um die 1.9'er Platine gleichzeitig
    mit einer 1.3'er zu betreiben.
    Wobei meine DTV-Adapter-Platine von vornherein den Anschluss hat was mir die Sache zusätzlich erleichtert.



    Und noch ein Bild wie die voll-bestückte 1.9'er im Detail aussieht, für das WIKI mache ich nochmal auf der Arbeit ein schöneres Bild, das bekomme ich hier mit dem Licht nicht richtig hin.


    IMG_0176s.jpg


    Den Programmier-Stecker wird am Ende kaum jemand benötigen.
    Und die Stiftleiste habe ich jetzt auch zum ersten Mal bestückt weil ich das Ding bequem auf #9 jumpern wollte, was auch einwandfrei geklappt hat.

  • Thema Baugröße und Bauteile auf der Unterseite:


    Ist es nicht möglich, den Mega32L unter den SD Sockel zu verpflanzen, also auf der Oberseite der Platine? Habe hier noch eine unbestückte 1.6 mit dem CSD Sockel, da scheint ja noch massig Luft dann zwischen SD Karte und Mega 32 zu sein. Evtl passen da auch noch andere SMD Bauteile mit drunter? Dann wäre die Unterseite wieder frei, die Platine noch ein Stück kleiner, und doch genug Platz für bedrahtete Bauteile.


    War nichtmal ein Problem wegen Lieferbarkeit dieser Sockel? Mir gefallen die sehr gut, vor allem dieser stand-off, so dass man Bauteile darunter verstecken kann.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    1. 10 open1,8,15 : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    2. 20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    3. RUN
  • Hallo Shadowolf!
    Ich hätte auch gerne wieder ein paar von den 1.9ern. Ich werde mal den Bedarf bei uns (Austria) abklären und dann Bescheid geben. Als Vorschlag für die 2.0er würde ich den Mega644V-10AU verwenden, ich glaub Unseen wollte den für eventuelle Zusatzfeatures haben. Somit könnte man zweigleisig fahren. Bis z ur 1.9er mit einer "kleinen" Firmeware und ab 2.0 dann mit Jiffy Unterstützung, D64 & G64 Support, etc.
    Ist aber (leider) wieder nur ein Vorschlag meinerseits...


    lg,
    znarF

  • Wie interessant wäre das eigentlich, den Mega644V-10AU statt des Mega32L-8AU einzusetzen?


    Code
    1. crystal:~/src/avr/mmc2iec/sd2iec$ make CHIP=m32
    2. avr-size -A obj-m32/sd2iec.elf|grep -v debug
    3. obj-m32/sd2iec.elf :
    4. section size addr
    5. .bootloader 8 30712
    6. .text 23422 0
    7. .data 6 8388704
    8. .bss 1664 8388710


    Aktuelle Entwicklungsversion ohne UART-Debug-Ausgaben, d.h. mit Read-Only-D64-Support und U1/U2 (Infocom-Adventures und CP/M auf dem C128 gehen! =) ).


    Quote

    Als Kandidat für eine potenzielle 3.0 kämen möglicherweise die ATXMega in Betracht.


    Erwähnte ich schonmal, dass ich den AT91SAM7S256 interessant finde? ;-)


    Hallo Shadowolf!
    Bis z ur 1.9er mit einer "kleinen" Firmeware und ab 2.0 dann mit Jiffy Unterstützung, D64 & G64 Support, etc.


    Für zwei dieser drei Features sollte der mega32 auf jeden Fall noch ausreichen. Beim dritten frage ich mich ob es sinnvoll ist - da kein Floppycode ausgeführt werden kann besteht eigentlich kein Bedarf für G64-Dateien, oder?

  • Unseen


    23 kB belegt? Ist doch prima, sind also noch 7 kB frei, so etwa 23 Prozent.
    Sieht erstmal nicht nach einem echten Problem aus.
    Zumindest nicht auf User-Ebene und einzelne Exemplare mit dem 644'er wären ja nicht das Problem.


    Das Display sollte deutlich unter 1 KB machbar sein mit 32 Byte SRAM für den "Bildschirm-Speicher".


    Hmm, AT91SAM7S256, ja?
    Ist ein wenig sehr überdimensioniert?
    Atmel hat jetzt auch AVR's mit FPGA. :-)


    Ich nehme das jetzt mal Ernst.
    Ich sehe ja ein, dass deutlich mehr SRAM überaus praktisch wären aber der AT91SAM7S256
    kostet bei Reichelt 10,20 Euro das Stück und hat 64 Pins mit 0,5 mm Abständen.
    Dazu kommt, dass die Entwicklung erheblich aufwendiger sein dürfte, für so ein Teil braucht man
    da bald schon ein Betriebs-System, die ersten paar KB gehen wahrscheinlich nur für Initialisierungen drauf.


    Dann lieber einen AT32UC3B1128, der hat nur 48 Pins.
    Auf der Seite der Toolkette unterstützt Atmel die auch besser, es gibt das AVR32-Studio und GCC.
    Nur wird der bisher bestenfalls auf Eva-Boards ausgeliefert - und ich habe so ein Ding in der Firma rumliegen. :-)



    znarF


    Für Dich und Swasti habe ich noch zwei Platine der Version 1.9'er hier rumliegen die als Bausätze rausgehen sollten.
    Die PN dazu habe ich aber bisher nicht bekommen...


    Der Umstieg auf den Mega644 erfordert keine 2.0 der Platine, das können wir ohne Änderungen für lediglich mehr Geld bekommen.


    x1541


    Unter den Sockel zu gehen ist nicht so komisch, da man dann nicht mehr im Fehlerfall messen kann.
    Und die bedrahteten Teile müssen sowieso vor dem Sockel liegen, inklusive des Quarzes, die Leitungen da alle durchzufädeln macht das Layout bestimmt weder einfacher noch robuster gegen Störungen.


    Ich habe mich für Teile auf der Unterseite entschieden weil ich diese dann grösser machen konnte und ich bei der 1.6'er Version nicht den Eindruck hatte, dass die einseitige Bestückung als Pluspunkt akzeptiert wurde.
    Als negativ wurden eher die kleinen Teile aufgenommen.
    Mit den bisherigen FET's und 0805 Widerständen wäre einseitig bestückt auf kein Problem.


    Für eine 1.10 ist aber sicherlich noch Zeit.


    Die Platine um 1/2 cm kürzer zu machen bringt auch nicht viel.
    Dann könnte ich bestenfalls 32 statt jetzt 30 Platinen auf einen Nutzen bringen.
    Wenn ich die bei Dir mitfertigen liesse würden die dann wahrscheinlich auch nicht wirklich günstiger werden.


    Mit der Lieferbarkeit der SD-Sockel müssen wir uns fürchte ich mal überraschen lassen.
    Momentan wüsste ich keine echte Alternative.
    Und wie es aussieht hat Alps mit dem SCDA4A0400 einen neu im Programm der den bisher verwendeten
    SCDA1A1401 verdächtig ähnlich sieht.


    Edit: ich habe das mal hingeschoben.
    Ob sich das so layouten lässt kann ich nicht sagen.
    Aber die Platine ist jetzt 46 mm statt 52 mm lang, nicht so der Gewinn.
    Ausserdem ist der Quarz dann 12 mm vom Controller weg und die Leitungen laufen durch den SD-Sockel,
    man kann den Controller bestimmt noch ein wenig schieben, aber mit den Leitungen das gefällt mir nicht.
    Der Programmier-Anschluss ist dann überhaupt nicht mehr bestückbar.


    test.png


    Und wie gesagt, im Fehlerfall muss man den SD-Sockel ablöten.
    Wenn der Quarz, der Spannungsregler und die FET's erstmal bestückt sind macht das bestimmt keine Freude.


    Edit: Na okay, 45,2 mm und der Auto-Router kann es routen.


    test2.png


    So richtig überzeugt bin ich aber dennoch nicht.

  • 23 kB belegt? Ist doch prima, sind also noch 7 kB frei, so etwa 23 Prozent.
    Sieht erstmal nicht nach einem echten Problem aus.


    Mal schauen... Ich habe spasseshalber mal die letzten 100 Revisionen compilieren lassen und die Codegrössen geplottet:


    test.png


    Die deutlichsten Sprünge sind (von rechts nach links):

    • Blockzugriff auf D64 (da hätte ich anders aus meinem privaten Branch mergen müssen - das waren mal drei Commits)
    • readdir/opendir für D64
    • Dateien in M2I lesen/schreiben
    • M2I Minimalsupport (Mount/Unmount/Label und ein paar Dummyroutinen)
    • Wildcard-Support beim Laden
    • Wildcard-Support für Directories
    • Turbodisk (plus Infrastruktur für weitere Speeder)
    • CRCs in Richtung SD-Karte
    • Unterverzeichnisse (2*)


    Ich habe das Gefühl als würden switch/case-Konstrukte überdurchschnittlich viel Platz belegen.


    Quote

    Hmm, AT91SAM7S256, ja? Ist ein wenig sehr überdimensioniert?


    Oooch, der Gameboy Advance basiert auch auf einem ARM (mit 16MHz) und dafür gibts einen unter der GPL stehenden NES-Emulator, welches auch einen 6502 verwendet hat. Die Sourcen sind allerdings ziemlich kryptisch.


    Aber nimm nicht alles ernst was ich schreibe, insbesondere wenn ein passender Smiley dahintersteht.



    Ich halte das "Controller unter SD-Slot"-Layout übrigens auch für unpraktisch.

  • Mal schauen... Ich habe spasseshalber mal die letzten 100 Revisionen compilieren lassen und die Codegrössen geplottet:


    Ist ja ganz witzig aber was wolltest Du nun konkret damit sagen? :)


    Ja oder nein?


    Mir sind 3,50 Euro Aufpreis nicht zu viel wenn denn die Aussicht besteht, dass der zusätzliche Speicher auch und über die Entwicklung hinaus genutzt wird.


    Allerdings ist auch die Frage, was mit den 1.6'er Geräten ist, für die müsste man dann eventuell auf Funktionen verzichten, damit das noch in den Speicher passt.


    Meine Aufgabe ist ja "nur", dass möglich zu machen und für weniger als 3,50 Aufpreis, insgesamt so günstig wie möglich.


    Wir müssen das allerdings nicht in den nächsten Tagen endgültig entscheiden.
    Momentan habe ich 22 "Vor-Bestellungen", das ist noch erheblich zu wenig um in hektische Aktivität auszubrechen.
    Vor der 2. KW wacht Deutschland wohl auch nicht auf, Bauteil-Anfragen sind gerade ein wenig schwierig.


    Und in 1-2 Wochen sieht es mit der Software vielleicht auch wieder ein wenig anders aus.


    Quote

    Oooch, der Gameboy Advance basiert auch auf einem ARM (mit 16MHz) und dafür gibts einen unter der GPL stehenden NES-Emulator, welches auch einen 6502 verwendet hat. Die Sourcen sind allerdings ziemlich kryptisch.


    Aber nimm nicht alles ernst was ich schreibe, insbesondere wenn ein passender Smiley dahintersteht.


    Doch ich nehme das ernst, und sei es, um das mal durchzudenken.
    Die AVR's zeichnen sich nun einmal durch einen eklatanten Mangel an SRAM aus.


    Andere Controller sind aber auch nicht so leicht zu programmieren, die AVR's sind was für die ganze Familie. :-)



    Die Nische für das MMC2IEC ist offenbar im Low-Cost Segment deutlich unter 20 Euro.
    Sowas wie die 1541-Ultimate ist sicherlich der Kracher, für den Standalone-Betrieb allerdings deutlich zu klobig.
    Wenn der Kollege mit einem kleineren FPGA und deutlich kleinerer Platine (und hochwertigerem SD-Sockel) das Segment bei 30 Euro anpeilen würde, dann würde die Nische für das MMC2IEC doch etwas eng werden.


    Und Kompatibilität ist nicht alles, ich bin schon sehr gespannt auf den nächsten sd2iec Fastloader.


    Quote


    Ich halte das "Controller unter SD-Slot"-Layout übrigens auch für unpraktisch.


    Damit würde ich sagen ist das Thema vom Tisch wenn es nicht noch weiteren Diskussions-Bedarf gibt.
    Bei einem aufgebautem und getesteten Fertig-Gerät würde ich das vielleicht so machen, unter Verwendung eines SMD-Quarzes und kleinerer Teile, bei Bausätzen ist während des Aufbaus allerdings immer mit Problemen zu rechnen.


  • Damit würde ich sagen ist das Thema vom Tisch wenn es nicht noch weiteren Diskussions-Bedarf gibt.
    Bei einem aufgebautem und getesteten Fertig-Gerät würde ich das vielleicht so machen, unter Verwendung eines SMD-Quarzes und kleinerer Teile, bei Bausätzen ist während des Aufbaus allerdings immer mit Problemen zu rechnen.


    Ich bin ja schon still :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    1. 10 open1,8,15 : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    2. 20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    3. RUN
  • anscheinend sind die Platienen das teueste an dem mmc2iec, deswegen würde ich vorschlagen, verwenden wir einen pentium2 slot prozessor und löten die Bauteile direkt drauf dann brauchen wir garkeine, und ist auch noch billiger als atmel przessor :roll2: :roll2: :roll2: :roll2: :roll2:


    nein jetzt im ernst wozu um jeden mm2 feilschen, mich würde es auch nicht stören wenn die Platiene doppelt so groß wäre.

  • So war das ja nicht gemeint. :)
    Wir brauchen schon Vorschläge und wie Du gesehen hast habe ich mir damit auch Mühe gegeben und es nicht einfach abgebügelt.


    Von mir war es auch nicht so gemeint aber ich hatte gerade keine Lust eine umfassende Abhandlung zu schreiben und unterm Strich hast Du einfach recht in Bezug auf Nachbaubarkeit und Servicefreundlichkeit von Bausätzen. Ich hab ja beim NeoRAM das gleiche, wenn ich das nur für mich gemacht hätte wären da keine DILs drauf und vielleicht nichtmal ein TTL Baustein von der Stange.


    Gibt es eigentlich was zum Thema Spannungsregler zu sagen? Da war doch mal in der Diskussion auf einen 3,3V Typen zu gehen?

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    1. 10 open1,8,15 : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    2. 20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    3. RUN
  • Quote

    Gibt es eigentlich was zum Thema Spannungsregler zu sagen? Da war doch mal in der Diskussion auf einen 3,3V Typen zu gehen?


    Welchen Vorteil hätte denn ein 3,3V Spannungs-Regler gegenüber dem jetzt verbauten 3,0V Spannungsregler?


    Der LP2950-3,0 ist allerdings auch nur drauf, weil von Reichelt und CSD keinerlei 3,3V Typen angeboten werden.
    Jedenfalls nicht im TO92.
    Einen Regler im SOT23-5 wollte ich nicht nehmen da zu fummelig und genauso wie in SOT223 wird dann auch die benötigte Fläche deutlich grösser.


    Einen dritten Lieferanten mit aufzunehmen wäre auch nicht der Bringer, momentan hoffe ich sogar, dass CSD die restlichen Teile von Reichelt mit anbietet.



    Thema Leiterplatten, eventuell lasse ich die bei einer Sammel-Bestellung in China mit fertigen, die Qualität scheint jedenfalls ganz gut zu sein, der Besteller hat da schon Erfahrung.


    Was haltet Ihr davon, wenn ich die Dinger in blau fertigen lasse?


    Habe ich gerade angefragt aber nach dem Rechen-Beispiel für 10 Euro-Karten und da von dem MMC2IEC 9 Stück auf eine Euro-Karte passen könnten wir auf unter 1 Euro pro Platine kommen.