Hello, Guest the thread was called11k times and contains 122 replays

last post from skoe at the

Zwischenbericht zum Experiment "open1541"

  • Hallo,


    hier mal ein Zwischenbericht aus dem Projekt, dem ich jetzt spontan mal den Arbeitstitel "open1541" gebe.


    Wer nicht weiß, worum's geht: Siehe die letzten Posts in RTC sinnvoll? .


    Den LPC habe ich zum Laufen bekommen, erstmal PLL, UART, Timer und so dieses grundlegende Geraffel. Dann habe ich in den letzten Tagen mit einer zyklengenauen 6502-Emulation im Timer-FIQ (Fast Interrupt) begonnen. Im Moment sind erst eine Handvoll Opcodes implementiert, die aber vollständig, also mit Flags, Zusatzzyklus bei Bxx Seitenüberschreitungen etc. Es ist auch schon vorgesehen, für die verschiedenen Speicherbereiche spezialisierte Lese/Schreibfunktionen zu benutzen (Sprungtabelle), von denen momentan nur RAM-Read implementiert ist. Einerseits sind noch Optimierungen möglich, andererseits kommen sicher noch Sachen dazu. Die ersten Ergebnisse sind nicht prickelnd, aber akzeptabel. Natürlich kann man auch noch das Konzept überdenken, dass immer nur exact eine Instruktion pro IRQ ausgeführt wird, aber dass macht die Sache ziemlich leicht handhabbar.


    Zum Messen habe ich im Hauptprogramm eine Schleife, die eine Sekunde lang zählt und dann die Anzahl der Loops ausgibt.


    Volle Geschwindigkeit: 2282748
    Code im Flash ohne MAM: 571100
    Code im Flash 2ws: 629143 (standard)
    Code im Flash 1ws: 865076 (flash overclocked)
    Code im RAM: 951207 (IRQ-Vektor noch im Flash)


    Man sieht also, das beim Ausführen aus dem RAM bei 60 MHz noch etwa die Hälfte für die Emulation von allem, was nicht CPU ist, übrigbleibt. Man merkt auch, dass der Flash doch ein Flaschenhals ist. Beim LPC ist der 128 bit breit angebunden (= 4 32-Bit-Instruktionen), bei 60 MHz ist 1 Flash-Zyklus auf 3 CPU-Zyklen empfohlen. Rechnerisch passt's also. Es gibt auch einen MAM (Memory Acceleration Module), der drei dieser Lines vorspeichert (Prefetch, Branch Trail, Data). Mit meinen Sprungtabellen für Opcodes und Speicherzugriffe scheine ich den Mechanismus aber recht effektiv auszuhebeln :-( Na mal sehen. Wen's genauer interessiert: um10120-1.pdf, Kapitel 4.


    Unseen: Danke nochmal für den Hinweis mit dem einen Zyklus bei den VIA-Registern. Beim Schreiben ist mir eine Möglichkeit eingefallen, die ohne Busy Wait oder Extra-IRQ auskommt: Der LPC hat für den Timer, den ich für die CPU benutze, 4 Match Register. Das erste nehme ich für die CPU-Emulation. Mit den anderen kann man das Kunststück anstellen: Man kann einen Pegel festlegen, der beim Erreichen des Zeitpunkts auf bestimmte Datenleitungen gelegt wird. Man kann also t + 1 programmieren, den Pegel zwischenspeichern und den Rest macht die Hardware. Beim Lesen würde ich momentan zu Busy Wait neigen, was besseres ist mir da noch nicht eingefallen. Beide Möglichkeiten lassen jedenfalls den IRQ-Latenz-Jitter verschwinden.


    Im Moment denke ich darüber nach, ATN-ACK wie in der 1541 extern umzusetzen. Wenn sowieso schon FETs für die Leitungen benutzt werden, kann man vielleicht auch einen mehr benutzen, um den Mechanismus so umzusetzen. (Mir schwebt was vor, wie man die zusammenknüppern müsste. Bin mir aber nicht so sicher. Shadowwolf: Kannst Du sowas ausklügeln?) Vielleicht kann man auch einen preiswerten 74LSirgendwas für alle Leitungen und diese Logik benutzen.


    (Teil 2 kommt gleich, will erstmal abschicken)

  • ...Teil 2:


    Weil mir demnächst mein LPC2134 zu eng werden wird und ich dann auch einiges an Peripherie ranknüppern will, stehen jetzt Gedanken zu einer Entwicklungsplatform an. LPC2136 sollte es mindestens sein, wg.RAM. SD-Karte muss ran, ein 2*16 EA DOG-Display liegt hier auch schon rum, User-Port Parallelkabel wollte ich auch frei halten.


    Option 1: Bread Board


    Nein, bitte nicht, ist jetzt schon unhandlich.


    Option 2: Prototyp selbst bauen


    Im Moment bin ich dabei, die 64 Beinchen sinnvoll zuzuordnen. Dabei habe ich erstmal die Software und die Funktionalität im Sinn, nicht das Layout. Aber da kommt mir die Frage: Wie kann man auf die Idee kommen, die I/O Pins bunt gemischt über die Pins zu verteilen, statt sie einen nach dem anderen aufzureihen?! Das sieht an den Atmels etwas übersichtlicher aus.


    Die Leiterplatte würde ich mir selbst ätzen, ob das mit Overhead-Folie aus dem Tintenspritzer bei 0,5 mm pitch was wird? Außerdem sehe ich mich eher auf der Software-Seite.


    Gibt es hier jemand, der beim Bau von ca. 3 Prototypen mithelfen kann? (Ich hab ja einen Namen im Kopf, aber der möchte ja momentan nicht basteln...)


    Option 3: Fertige Boards


    Man, da gibt's interessante Sachen. Aber bis jetzt noch nichts 100%iges dabei. Bei meinen Protoyp-Stückzahlen sind die Preise wohl nicht höher als beim Selbstbau.


    http://microcontrollershop.com…info.php?products_id=1312
    Dank des Dollarkurses sogar erschwinglich, hätten die nich statt des albernen Relais einen SD-Karten-Leser mit draufmachen können? Vor einer Bestellung aus Übersee schrecke ich aber zurück.


    Auktionsmonopolist Nr 160262194383
    Total oversized, nicht ganz der richtige Controller aber preiswert und hat einen SD-Karten-Leser


    Auktionsmonopolist Nr 360063764762
    Wäre auch denkbar, die Peripherie müssten man ja dann drumrumbasteln.


    Achja, wegen des AT91SAM: Dort soll der Flash nur 32 bit breit angebunden sein und dadurch langsamer zu sein. Hab ich irgendwo im mikrocontroller.net gelesen. Das stimmt mich skeptisch, trotz Atmel-Symphatiebonus.


    Was denkt ihr?


    Gruß,


    Thomas

  • Den Micro-Research Typen kenne ich. Hab schon mal ein AVR Board bei dem ersteigert.


    Aber wenn schon ARM warum dann keine Gameboys? Die haben Display und Expansionboard, Gehäuse und Tasten, SD Boards gibt es fix fertig. Und eine gute Entwicklungsumgebung. Und die gibt es zuhauf weil die bald keiner mehr will.

  • Aber wenn schon ARM warum dann keine Gameboys?


    Die GBA-Hardware sieht total lecker aus und ist wirklich sehr preiswert. Aber anscheinend hat Unseen recht mit den 16,67 MHz. Dann wäre der momentane Ansatz nicht umsetzbar. Es ist wirklich ein ziemlicher Unterschied, ob man einen Prozessor in einer Schleife emuliert oder ob die Emulation nach außen (!) zyklengenau sein muss.


    Stell Dir mal vor, dass der 6502 auch in Echtzeit laufen muss, während Daten von der SD-Karte geschaufelt werden oder das Display aktualisiert wird. Nur dann werden z.B. Fastloader zuverlässing funktionieren. Und eine bessere Idee als massiger Einsatz von IRQs habe ich dazu momentan nicht :-(


    Lass Dich von meinen Zweifeln aber bitte nicht vom Diskutieren abhalten. Vielleicht wird ja doch noch was aus der Idee.


    Wenn man wirklich alle Instruktionen in einer Schleife ausführt, die nach außen keine Auswirkung haben und auch von außen nicht beeinflusst werden, kann man sicher noch einiges an Performance rausholen. Deswegen will ich z.B. den ATN-ACK lieber in HW haben, weil das dann wieder ein Faktor weniger ist, den die Software in Echtzeit abbilden muss.


    Den 6502-Emulator habe ich zwar übrigens neu implementiert, mir aber einige Ideen von PocketNES und von David Sharp abgeschaut, auch auf den Frodo habe ich mal ein paar Blicke geworfen. Der von David Sharp scheint mir teilweise besser auf den ARM zugeschnitten zu sein während PocketNES schöne Ansätze zum Memory-Handling hat.


    Einige Implementierungen im PocketNES verwirren mich ziemlich, z.B. möchte ich folgendes lieber nicht einfach so übernehmen:



    Disclaimer: Ich möchte hier keine Geringschätzung ausdrücken, sondern nur sagen, dass ich den Code entweder nicht verstehe oder er nicht das macht, was er meiner Meinung nach machen sollte.


    Wenn ich die Quelltexte ein bischen aufgeräumt habe, mache ich sie übrigens öffentlich zugänglich.


    Gute Nacht!

  • Ok, seh ich ein, der GBA ist etwas mager. Aber was ist mit dem NDS? 33MHz Arm7 plus 66 MHz Arm9.


    Lohnt sich das wirklich? Man müsste ein Slot2-Modul designen das I/O-Ports, eine SD-Karte und festen Flashspeicher für einen Bootloader bietet und braucht ausserdem ein PassMe damit der NDS überhaupt den eigenen Code ausführt. Alternativ könnte man statt des festen Flashes und des PassMe auch ein Slot1-Flashmodul verwenden und evtl. auch den SD-Zugriff darüber leiten, aber ich bin mir nicht sicher wie gut die Module damit umgehen können wenn jemand im Betrieb die Karte wechseln möchte. Zudem fehlt ein Teil der netten Peripherie die ein Microcontroller sonst mitbringt - Debugging via UART ist komfortabler als Debugging via Display weil man die Daten loggen kann.


    Laut GBATEK hat der ARM9 im NDS übrigens ziemlich viele Waitstates bei ungecacheten Speicherzugriffen, das könnte schon ein Killerargument in diesem Projekt sein.


    Insgesamt wird das ganze ziemlich gross und kommt wahrscheinlich in die Preisregionen einer 1541U - zumindest ich würde da fürs "Endprodukt" eine Eigenbauhardware bevorzugen, worauf man anfänglich entwickelt ist dagegen relativ egal.


    skoe: Ich habe mit den AT91ern keine Erfahrung, aber laut Datenblatt soll das Flash 0 oder 1 Waitstate (je nach Takt) haben - flott genug? Vergiss bei ausländischen Shops/eBay-Anbietern nicht die 19% EuST die der Zoll verlangen wird.

  • Quote

    laut Datenblatt soll das Flash 0 oder 1 Waitstate (je nach Takt) haben


    Genau dieser eine WS bei 55 MHz führt zu Daumenwertartigen 27,5 MIPS wenn der Code aus dem Flash läuft, da mit 32 bit angebunden. (Angenommen 1 MHZ = 1 MIPS, was so nicht stimmt...)


    Wenn man annehmen würde, dass der LPC durch seine Prefetch-Buffer effektiv 0.5 Waitstates haben würde, wären dass ca. 40 MIPS. Ob diese Schätzung stimmt, hängt sicher sehr vom Code ab. Hab jetzt nicht nachgemessen/gerechnet, aber die 6502-Emulation tut (momentan) folgendes: FIQ (= cache miss), liest einen Opcode aus dem Speicher (= cache miss), springt anhand einer Sprungtabelle zum Code (= cache miss), führt dort 3 bis 5 billige Instruktionen aus und springt wieder zurück (wieder cache miss). So kommt man vielleicht auf mehr effektive Wait state. Als Cache Miss bezeichne ich das Nichtvorhandensein in der gepufferten Flash-Line.


    Wenn man sowieso mit dem Gedanken spielt, die CPU-Emu aus dem RAM mit 0 WS laufen zu lassen, gibt es ein Argument für den Atmel:


    91SAM7S256-AU 9,85 € hat 256+64 kByte
    LPC 2136 FBD64 10,50 € hat 256+32 kByte


    Das ist ein klares Plus für Atmel. Vielleicht sollte ich mir mal einen zulegen. Lässt der sich auch so komfortabel programmieren, ISP über UART? Oder braucht man Zusatzhardware?


    Also dann schau ich mal genauer ins Datenblatt:




    Die RTC ist mir eigentlich nicht so wichtig, wäre aber nett gewesen, wenn sie gleich mitkommt.


    Den D/A-Wandler wollte ich für einen ziemlich albernen Zweck einsetzen: Floppygeräusche. Aber auch darauf kann man verzichten.


    Bei den Timern sieht es aber für dieses Projekt ziemlich schlecht im SAM aus: Er hat einen frei konfigurierbaren, 32 bit breiten Real-Time-Timer. Dessen input ist aber was namens "Slow Clock" aus einem RC-Oszillator. Was Quartzgenau läuft, sind die 3 16-bit timer. Die scheinen in 2er-Potenzen vom MCK (Master Clock) ableitbar zu sein. Der MCK ist anscheinend frei vorskalierbar, dafür beeinflusst er aber auch andere Teile der Peripherie, man käme evtl. nur mit Abstrichen anderswo hier auf 1 MHz. Einen (geschweige denn 4 pro Kanal) Timer Match Interrupt oder so habe ich beim Überfliegen nicht gefunden :-( Als letztes bleibt noch der Periodic Interval Timer, der genau das macht, was der Name sagt.


    Diese Timer Mechanismen können IMHO leider bei weitem nicht das Abbilden, was der LPC kann: 1 MHz Takt in einem 32-bit-Register. 4 Match-Register, die beim Erreichen einen IRQ/FIQ auslösen können und/oder einen GPIO auf einen vorher definierten Wert setzen. Und das ganze ist zweimal drin.


    Schade, habe mich über die 64 kByte sehr gefreut. Aber die Timer-Sache ist ein K.O.-Kriterium. Oder irre ich mich da? Den Vergleich habe ich wirklich versucht, objektiv zu führen, habe auch keine Vorbelastung Richtung Phillips oder Atmel. Atmel hat mir den AVRs so eine clevere Hardware abgeliefert, das ist ihnen bei dem SAM wohl leider nicht gelungen. Scheint also doch nicht ganz grundlos, dass der LPC weiter verbreitet ist ("citation needed").


    Gruß,
    Thomas

  • Das ist ein klares Plus für Atmel. Vielleicht sollte ich mir mal einen zulegen. Lässt der sich auch so komfortabel programmieren, ISP über UART? Oder braucht man Zusatzhardware?


    AFAIK braucht man ein paar Widerstände, einen Quarz und ein abgeschnittenes USB-Kabel um den Bootloader im AT91SAM (SAM-BA) verwenden zu können.


    Quote

    Bei den Timern sieht es aber für dieses Projekt ziemlich schlecht im SAM aus: Er hat einen frei konfigurierbaren, 32 bit breiten Real-Time-Timer. Dessen input ist aber was namens "Slow Clock" aus einem RC-Oszillator. Was Quartzgenau läuft, sind die 3 16-bit timer. Die scheinen in 2er-Potenzen vom MCK (Master Clock) ableitbar zu sein. Der MCK ist anscheinend frei vorskalierbar, dafür beeinflusst er aber auch andere Teile der Peripherie, man käme evtl. nur mit Abstrichen anderswo hier auf 1 MHz. Einen (geschweige denn 4 pro Kanal) Timer Match Interrupt oder so habe ich beim Überfliegen nicht gefunden :-( Als letztes bleibt noch der Periodic Interval Timer, der genau das macht, was der Name sagt.


    Ja, das ist wohl eher auf ein RTOS optimiert das seinen Basistakt von dem Timer bekommt und alles weitere in Software macht.


    Quote

    Atmel hat mir den AVRs so eine clevere Hardware abgeliefert, das ist ihnen bei dem SAM wohl leider nicht gelungen.


    Mir wurde gestern noch empfohlen mal AVR32 genauer anzuschauen - zwar eine komplett neue Architektur, aber im Bereich der eingebauten Peripherie mit AVR8 vergleichbar. Leider wie AVR8 eine Havard-Architektur, nachladbare Plugins sind also nicht machbar.

  • Mir wurde gestern noch empfohlen mal AVR32 genauer anzuschauen - zwar eine komplett neue Architektur, aber im Bereich der eingebauten Peripherie mit AVR8 vergleichbar.


    Ich wollte gerade wieder lästern, dass es die nicht gibt.
    Aber die sind inzwischen bei DigiKey aufgetaucht.
    Etwa die AT32UC3B1128-AUT mit 128k/32k in TQFP48 für 6,85 Euro.
    Oder besser noch den AT32UC3B0128-A2UT in TQFP64 für 7,37 Euro.


    Langsam wird es vielleicht Zeit, sich die mal anzusehen.
    Und ein EVK1101 liegt hier auch schon viel zu lange rum, der Schaltplan dazu erschreckt mich erstmal nicht. :)


    Hmm, die Dinger können USB-on-the-go, die sind also auch USB-Host fähig.
    Man könnte also als Massen-Speicher USB-Sticks benutzen und zum Updaten der Firmware das Gerät
    direkt an einen PC anschliessen.
    Eine USB-Dose wäre deutlich günstiger als ein SD-Sockel - und leichter zu bekommen.


    Aber auch die AVR32 haben 0,5 mm Anschlüsse.

  • Quote

    Oder besser noch den AT32UC3B0128-A2UT in TQFP64 für 7,37 Euro.


    Hab mir gerade das Datenblatt des AT32UC3B0128-A2UT runtergeladen. CPU-mäßig klingt's wirklich wahnsinnig spannend. Dann habe ich mir die Timer angesehen: Sehen auf den ersten Blick identisch mit denen aus dem AT91 aus. Die haben wohl nicht etwa einfach die Peripherie recycled? Vielleicht könnte man trotzdem was damit machen, wenn die IRQs schnell genug sind.


    Man, jetzt bin ich neugierig geworden. Gibt's schon einen GCC und vielleicht einen Emulator wie Skyeye dafür? Ich such mal.


    Quote

    Hmm, die Dinger können USB-on-the-go, die sind also auch USB-Host fähig.


    Das erinnert mich an den LPC2148 mit 512k/40k im LQFP64 für 7,67 Euro bei Digikey. Ups, ist nur ein USB Device, kein Host.


    Dann hätten wir noch den LPC2368FBD100-S im LQFP100 für 6,35 mit 512k/58k mit USB Device (leider auch kein Host) und Ethernet.


    Nur der LPC2468FBD208-S für 9,81 hat 512k/98k mit USB OTG, Ethernet. Das Ganze wird dann mit LQFP 208 bestraft %-[


    Aber ich merk schon, ich nerv Euch damit... Euch beide kann man wohl nur begeistern, wenn Atmel draufsteht ;-) <schleim>Aber andererseits bin ich auf Eure Unterstützung angewiesen, denn alleine stemme ich das nicht.</schleim>


    Wie viel Flash/RAM muss man eigentlich für einen USB-Stack einplanen? USB Host hätte schon was. Da passten dan sogar USB-Festplatten oder CD-Laufwerke ran. Für aaaaaaaaaaaallllllle C-64-Software, die je gemacht wurde :-) Mit dem Ethernet würde uns sicher auch noch was einfallen. Aber da müssten doch dann noch solche Vicher auf die Leiterplatte, Tranceiver oder sowas. Was kostet sowas eigentlich?


    Jetzt mach ich mal weiter. heute will ich anfangen, eine Art simplen Monitor zu implementieren, mit dem man den 6502 single steppen lassen kann.


    Shadowolf: Was hältst Du von der Idee, die Bus-Transistoren und die 1541 ATN-ACK-Schaltung durch einen 74LS oder sowas zu ersetzen? Gibts da sowas wie 4 mal NAND mit Open Drain (???), mit denen man sowas machen kann? Wär unterm Strich vielleicht auch nicht teurer. Vielleicht würden dann auch ein paar Rs wegfallen? Aber Du merkst schon: Bei Hardware herrscht bei mir Halbwissen.


    Gruß,


    Thomas

  • Quote


    Aber ich merk schon, ich nerv Euch damit... Euch beide kann man wohl nur begeistern, wenn Atmel draufsteht ;-) <schleim>Aber andererseits bin ich auf Eure Unterstützung angewiesen, denn alleine stemme ich das nicht.</schleim>


    Also mich nervt das nicht und Atmel muss auch nicht draufstehen.
    Ich mag die AVR für kleine Projekte, jenseits AVR bin ich noch lange nicht.
    Aber solange ich die Dinger nicht programmiere kann mir das ja egal sein. :)
    Ich bremse vielleicht ein wenig um der Machbarkeit willen.


    Quote


    Wie viel Flash/RAM muss man eigentlich für einen USB-Stack einplanen? USB Host hätte schon was.


    Auch nicht viel mehr als jetzt.
    Die Atmel haben zusätzliches SRAM für die Endpoint-Puffer.
    Ich durfte auch schon ein Hands-On AVR-USB-Seminar mitmachen, nette Sache.
    Aber USB ist insofern grausam als das es quasi nur Software ist, mal eben schnell und basteln ist da nicht mehr.


    Quote


    Da passten dan sogar USB-Festplatten oder CD-Laufwerke ran.


    Vorsicht, da kommt dann schnell NTFS ins Spiel. Und ein CDFS zusätzlich ist auch nicht komisch.


    Quote


    Für aaaaaaaaaaaallllllle C-64-Software, die je gemacht wurde :-)


    Wie jetzt, dafür reichen 8 GB USB-Sticks nicht aus?
    Okay, wenn man alle 12 Crack-Varianten von jedem Spiel haben will, dann eher nicht. ;)


    Mal im Ernst, 1 GB sind rund 2900 komplette Disketten, beide Seiten.
    Wie gross kann der C64 Daten-Bestand denn ernsthaft sein?


    Quote


    Mit dem Ethernet würde uns sicher auch noch was einfallen. Aber da müssten doch dann noch solche Vicher auf die Leiterplatte, Tranceiver oder sowas. Was kostet sowas eigentlich?


    Ethernet ist ziemlich sinnlos an einer für den IEC gedachten Hardware. :)
    Vor allem, wenn man schon USB hat.


    Ethernet habe ich aber noch nicht wirklich auf Leiterplatte gebracht, kommt noch.


    Quote


    Shadowolf: Was hältst Du von der Idee, die Bus-Transistoren und die 1541 ATN-ACK-Schaltung durch einen 74LS oder sowas zu ersetzen? Gibts da sowas wie 4 mal NAND mit Open Drain (???), mit denen man sowas machen kann? Wär unterm Strich vielleicht auch nicht teurer. Vielleicht würden dann auch ein paar Rs wegfallen? Aber Du merkst schon: Bei Hardware herrscht bei mir Halbwissen.


    Der Grund warum sowas auf dem SD2IEC nicht drauf ist: Platz.
    Ein IC wäre entweder erheblich grösser gewesen oder aber noch schlimmer, kaum zu beschaffen und kaum noch durch Hobby-Löter verarbeitbar.
    Ein 7406 in SO14 sollte es tun.


    Die nackte Platine unter 10 Euro ist mein vorerst vage gesetztes Ziel.

  • Momentan komme ich mit meinem Monitor nicht weiter: UART geht nur in eine Richtung. Aber im Booter gehen beide. Dewegen hänge ich jetzt wieder demotiviert im Forum rum...


    Quote

    Aber USB ist insofern grausam als das es quasi nur Software ist, mal eben schnell und basteln ist da nicht mehr.


    Den Eindruck hatte ich auch, als ich im Linux-Kernel mal was daran ändern musste.


    Quote

    Ich bremse vielleicht ein wenig um der Machbarkeit willen.


    Ist ja auch richtig so. Genau deswegen will ich auch erstmal ein halbes d64 (mehr flash hab ich nicht) und das 1541-ROM reincompilieren und die Sache grundlegend zum Funktionieren bekommen. Aber ich würde ungern einen großen Teil auf dem "falschen" System implementieren. Besonders, wenn ein großer Teil in Assembler implementiert ist und bestimmte Eigenschaften der Hardware benutzt (deswegen reite ich auch so auf den Timern rum).


    Quote

    Ein IC wäre entweder erheblich grösser gewesen oder aber noch schlimmer, kaum zu beschaffen und kaum noch durch Hobby-Löter verarbeitbar.
    Ein 7406 in SO14 sollte es tun.


    Als Lötkiller haben wir ja unsere 0,5 mm QFP :-) Die haben auch alle Kandidaten gemeinsam. Könnte man die ATN-ACK-Sache auch mit einem FET mehr machen? Ich weiß, das ist nur ein Detail, aber es kam mir beim Durchdenken der Sache so in den Sinn.


    Quote

    Die nackte Platine unter 10 Euro ist mein vorerst vage gesetztes Ziel.


    Tja, und bei der chaotischen Pinanordnung beim LPC und auch beim SAM wird eine einseitige wohl kaum drin sein. Beim AVR32 habe ich mir die Pinbelegung noch nicht angesehen.


    Hältst Du eine Userport-Anbindung für sinnvoll? Braucht sowas jemand? Sind 10 GPIOs, wovon 8 aufeinanderfolgend sein sollten.


    Ahh, beim Schreiben fallt mir auch der vermutliche UART-Fehler ein: PINSEL - das Register für die Pin-Multiplexerei. Hatte ich schon beim TX vergessen. Schau gleich mal nach...


    Thomas

  • Ja, es war PINSEL. Und ich hatte es nichtmal vergessen, sondern war bei Copy+Paste in der Zeile verrutscht.


    Quote

    Vorsicht, da kommt dann schnell NTFS ins Spiel. Und ein CDFS zusätzlich ist auch nicht komisch.


    Ach, mein DVD-Alles-Player mit USB kann auch nur FAT. Und wenn ich eine externe Platte hätte, wäre sie auch FAT, weil ich viel unter Linux unterwegs bin und da NTFS weh tut.


    Die CD war nicht ganz ernst gemeint.


    Quote

    Wie jetzt, dafür reichen 8 GB USB-Sticks nicht aus?


    Mir reichen meine beiden 512 MByte und 2 GB Karten auch dicke aus. Und die sind auch nur einigermaßen gefüllt, weil ich mal die HVSC raufkopiert habe, um den SID-Player im MMC64 auszuprobieren. Hatte extra ein Smiley hingemalt ;-)


    Ich habe ja auch Unseen schon angedeutet, dass ich die Multi-Partitions-Unterstützung im sd2iec nicht für sooooo sinnvoll gehalten hab. Wobei in der SD-Spec IMHO auch steht, dass auf einer SD-Karte nur eine Partition sein sollte. Aber das juckt einem beim fdisk-benutzen natürlich auch nicht. (Bitte nicht falsch verstehen: Das heißt nur, das ich das Feature nicht unbedingt brauche. Andere sehen das sicher anders)


    [/quote]Ethernet ist ziemlich sinnlos an einer für den IEC gedachten Hardware. :)
    Vor allem, wenn man schon USB hat.[/quote]


    Ich gebe zu, ich hab erst die IC-Feature-Matrix durchgeblättert und mir dann überlegt, was man damit anfangen könnte. Mhh, Dateien und Images von einer Art Netzlaufwerk öffnen.... über ein TFTP-ähnliches Protokoll. Na gut, braucht kaum jemand. Kein Grund, die Hardware teurer zu machen.


    Und es stimmt auch, dass man über USB sowas auch machen könnte. Wobei leider das Mass Storage Device nicht das geeigneteste für das enfernte Öffnen von Dateien ist. Es erscheint dem Host nämlich nur als Block-Device und der fuhrwerkt dann selbst im FS rum. Ist dann doof bei konkurierenden Zugriffen. Und für das meiste andere braucht man wieder gleich eine Vendor- und Device-ID und einen Treiber.


    Aber diese ganzen Anwendungen stehen mir nicht im Vordergrund. Selbst das Display sollte man optional machen, damit es ein Low-Cost-Ding bleibt.


    Oh je, ich neige zum Labern...

  • Ich habe ja auch Unseen schon angedeutet, dass ich die Multi-Partitions-Unterstützung im sd2iec nicht für sooooo sinnvoll gehalten hab. Wobei in der SD-Spec IMHO auch steht, dass auf einer SD-Karte nur eine Partition sein sollte.


    Der Code läuft inzwischen auf mehr als nur SD, Leute mit IDE-Platten sehen die Unterstützung für mehrere Partionen wahrscheinlich etwas anders als SD-Nutzer. Der "teure" Teil davon ist eh die C64-seitige Partitionsunterstützung (d.h. das was den Floppies die Laufwerksnummer war) und nicht das Scannen nach PC-Partitionen.


    Ausserdem ist es angedacht irgendwann mal zu ermögliche, Diskimages nicht nur auf die aktuelle Partitionsnummer zu mounten sondern auch auf eine beliebige (freie) andere, damit mehrere Images gleichzeitig "offen" sein können. Kann aber noch dauern, das erfordert ein paar Low-Level-Umbauten.


    Hatte nicht vor langer Zeit mal jemand nach einer Möglichkeit gefragt um eine Art Festspeicher auf dem Teil zu haben? Ich suche gerade nach einer Anwendung/Ausrede um ein wenig mit Dataflashes (bis zu 4MByte im SO8-Gehäuse, via SPI ansprechbar - in grösseren Gehäusen AFAIK bis 16MByte) herumzuspielen. ;-)

  • Hatte nicht vor langer Zeit mal jemand nach einer Möglichkeit gefragt um eine Art Festspeicher auf dem Teil zu haben?

    Hm, ja, ich erinnere mich - irgendwo im Thread zum mmc2iec oder sd2iec war da mal was.
    Die Idee war, das onboard RAM als ein Laufwerk anzusprechen (z.B. LW 9) und die SD-Karte als ein anderes (z.B. LW 8).