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

Quote from Diddl

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!

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

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 from skoe

Gibt's schon einen GCC und vielleicht einen Emulator wie Skyeye dafür? Ich such mal.

Das mit dem GCC war eine blöde Frage, bin ich vorher doch selbst schon drüber gestolpert.

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...