Hallo Besucher, der Thread wurde 20k mal aufgerufen und enthält 122 Antworten

letzter Beitrag von skoe am

Zwischenbericht zum Experiment "open1541"


    Die Hardware dürfte wohl auch insgesamt nicht so das Problem sein, mehr schon das Emulations-Timing zu halten, könnte ich mir jedenfalls vorstellen.


    Aber Du wirst das schon hinkriegen. ;)

    Zitat von Camigo

    Also wofür IC3D & IC3B gut sind ist klar, aber was Du mit IC3C bezwecken willst, entzieht sich mir ehrlich gesagt.
    Wenn Du das Data-Signal in Abhängigkeit zum ATN-Signal ändern willst (wozu eigentlich ?), dann könnte man das doch auch software-mäßig regeln, oder ?


    Die Orginallaufwerke verwenden eine ähnliche Schaltung um auf das ATN-Signal des C64 jederzeit reagieren zu können. Das könnte man zwar auch in Software nachmachen (sd2iec macht es so), aber skoe hat erstmal die Hardwarevariante vorgesehen weil für die Emulation eh schon genug Rechenzeit verbraten wird.

    Zitat

    Habe mir gerade mal die technischen Daten zum 'IRLR 120L' angeguckt, u. die ist wirklich gut dafür geeignet.


    Danke, dass Du Dir die Zeit genommen hast. War mir auch etwas unsicher, weil mir die meisten Daten gar nichts sagen. Soweit ich verstanden hab, sollte für den Zweck Ron niedrig sein und und Vgs klein genug sein, damit er bei 5V voll durchschaltet. Oder so ähnlich. Und klein und billig...


    Zitat

    Naja, ich mag Tantals deswegen lieber als normale Elkos, weil die Lebensdauer höher ist - von wegen kein Elektrolytverlust - und weil mir die Bauform eher zusagt.


    Hatte ein bisschen rumgegoogelt mid dem Ergebnis, das sie angeblich empfindlich gegen schnelles Laden/Entladen und deshalb am Spannungsregler nicht ideal sein. Und politisch inkorrekt. Aber auch Deine Fakten habe ich gefunden. Scheinen wohl beide Vor- und Nachteile zu haben. Also lasse ich Platz und Preis entscheiden :-)


    Zitat


    Also wofür IC3D & IC3B gut sind ist klar, aber was Du mit IC3C bezwecken willst, entzieht sich mir ehrlich gesagt.
    Wenn Du das Data-Signal in Abhängigkeit zum ATN-Signal ändern willst (wozu eigentlich ?), dann könnte man das doch auch software-mäßig regeln, oder ?


    Guck mal auf http://www.c64games.de/artikel/Schaltplan_1541.pdf. Diese Beschaltung soll UA1, UD3 und UB1 (unten rechts) nachbilden. Hoffentlich tut sie das auch :-) Wie Unseen schon geschrieben hat, hast Du recht: Dass kann man auch in Software machen, im sd2iec funktioniert das ja auch sehr gut. Da ich aber sowieso Treiber für den Bus brauche, wollte ich diese Sache gleich der Hardware überlassen, ist einen Echtzeitaufgabe weniger.


    Und der 74HCT03 auch nicht teurer als die FET-Beschaltung im sd2iec, vielleicht aber etwas größer.


    Zitat

    Es wäre wohl noch 'ne gute Idee, dem ATN-Signal ebenfalls eine Treiberstufe nachzuschalten.


    Für ATN habe ich keinen Treiber, weil ich nicht plane, ATN anzusteuern (macht die 1541 auch nicht). P0.22 wird ATN IN. Ich hab darüber nachgedacht, das freie Gatter an SRQ ranzuknüppern, dann könnte man für eine 1571-Emulation benutzen. Aber da ich noch nicht mal weiß, wie genau SRQ funktioniert, hab ich's nicht eingezeichnet.


    Zitat

    Die Hardware dürfte wohl auch insgesamt nicht so das Problem sein, mehr schon das Emulations-Timing zu halten, könnte ich mir jedenfalls vorstellen.


    Kommt immer drauf an, in welchem Gebiet man sich zuhause fühlt :-) Bei dem Timing bin ich inzwischen ganz zuversichtlich. Es sind zwar noch einige Sachen zu tun, die auch Echtzeit sind (Lesekopf, VIA-Timer) aber andererseits hab ich für eine Beschleunigung der CPU-Emu auch noch ein paar Ideen. Die ist jetzt übrigens fast komplett (u.a. fehlt noch der BCD-Modus). Bevor ich sie wirklich auf den 1541 ROM loslasse, will ich aber noch ein Test-ROM-Image implementieren. Das kann man dann nach jeder Änderung mal durchnuddeln lassen.


    Zitat

    Aber Du wirst das schon hinkriegen. ;)


    Danke für Dein vertrauen ;-)

    So, bevor ich hier zum Zitier-Weltmeister mutiere, haue das jetzt einfach mal ausnahmsweise, scheinbar zusammenhangslos, ohne quoten runter:


    @ Unseen


    Damit hast Du wohl wahr. Prinzipiell ist es ja immer von Vorteil - mal von der gesparten Rechenzeit abgesehen -, wenn die Hardware-Bedingungen sich der emulierten Hardware in etwa schon annähern.



    @ skoe


    Vor einem Spannungsregler bzw. nach einer Gleichrichtung, würde ich persönlich übrigens einen Tantal-Elko auch nicht einsetzen. Aber danach - kein Problem (behaupte ich hier einfach mal ganz dreist).


    Falls Du auch einen 5V - Spannungsregler einsetzen willst, könntest Du theoretisch auch 'ne gewöhnliche Silizium-Diode (z.B. '1N 4001' oder sowas) als Verpolungsschutz nehmen. Der relativ hohe Spannungsabfall daran (ca. 0,7 V) wäre bei der entsprechenden Speisespannung ja vernachlässigbar.
    Aber nur FALLS. Wenn nicht, fällt an so'ner MOS-FET - Diode natürlich viel weniger (kaum) Spannung ab.
    Ich muß noch dazu sagen, dass ich nicht so der große Dioden-Experte bin, aber nach meiner Einschätzung wäre die, mit der Du schon 'liebäugelst' ganz gut geeignet.


    Zu IC3C:
    Habe mir gerade mal den Schaltplan von der '1541' über Deinen Link gezogen. Muss mir mal angucken, was da IEC_Bus-mäßig so abgeht. Vielleicht kann ich das danach dann besser nachvollziehen. :D


    Zu der Sache mit ATN und der Treiberstufe:
    Ich bin leider bekloppterweise von der Signalrichtung ausgegangen (sprich: vom Connector), als ich schrieb 'nachzuschalten'. Es hätte natürlich 'vorzuschalten' heißen müssen. Grundsätzlich ist es eigentlich immer'ne gute Idee, die externen Anschlüsse vom Innenleben zu entkoppeln (wie übrigens auch der komplette IEC-Bus in der '1541', sogar mit Schmitt-Trigger -Eingang -> na WOW).
    Aber zwingend nötig ist das natürlich nicht. Alles eine Frage, wie edel oder teuer das Innenleben ist, dass man evtl. vor der 'bösen' Außenwelt schützen will.


    Das SRQ-Signal sagt mir auch nichts (was allerdings auch nichts heißen soll). Erstmal (und nicht nur ERSTMAL) würde ja schon völlig die 1541-Emulation ausreichen, denke ich mir.


    Falls Du irgendwelche Probleme haben solltest mit Deiner CPU-Emulation, sei es der BCD-Modus oder was auch immer, könnte ich Dir - bei Interesse - meine 6502-Emulation (einschließlich illergaler OP-Codes, allerdings in 68K-ASM) anbieten. Den würde ich dann aus meinem C64-Emulator, den ich mal auf'em AMIGA ge-code-t habe, rippen.
    Aber höchstwahrscheinlich ist die CPU-Emulation auch schon das einfachste am ganzen Projekt.


    Und wenn mal Probleme auftauchen sollten, dann frag einfach völlig ungeniert, hier gibt's so viel geballte fachliche Kompetenz, einer wird Dir ganz bestimmt weiterhelfen können. ;)


    Ich bin auf jeden Fall schon mal gespannt, wie's weitergeht.
    Auch wenn's schon diverse ausgereifte Konkurrenz-Projekte gibt - was eigenes is' was eigenes !
    Das Entwickeln von irgendwelchen Klamotten macht doch am meisten Spass, und wenn's am Ende dann auch noch funktioniert - Super Sache, was will man mehr ? Und man hat noch jede Menge dazugelernt. :winke:



    :dafuer:

    Zitat von Camigo

    Das SRQ-Signal sagt mir auch nichts (was allerdings auch nichts heißen soll). Erstmal (und nicht nur ERSTMAL) würde ja schon völlig die 1541-Emulation ausreichen, denke ich mir.


    Bezüglich SRQ kann vielleicht ich auch mal was nützliches beitragen, ich beschäftige mich jetzt seit Wochen damit:


    Wenn du irgendwann auch mal eine 1571 oder 1581 Floppy simulieren willst, dann hat dieses Signal für dich eine Bedeutung, sonst nicht. Der SRQ ist das Clock Signal für den schnellen Burst Transfer.


    Wenn du daran denkst den Burst Transfer zu unterstützen, dann sollte der SRQ (Takt) und Data auf ein 8 Bit Schieberegister geführt werden. Bei der 1571 wechselt das SRQ Signal ca. alle 2µs. Ein Bit wird imer bei steigender Flanke gelesen, in 32µs ist ein Byte übertragen. Ohne Schieberegister wird es nicht gehen da das erste Byte immer spontan übertragen wird. Du wirst Deine CPU Zeit nicht verschwenden wollen um ständig den SRQ zu überwachen ...

    > So, bevor ich hier zum Zitier-Weltmeister mutiere


    Das geht mir auch immer so, deshalb nehm ich jetzt auch mal den faulen Weg


    > bei der entsprechenden Speisespannung


    Das stimmt schon, wäre ja auch sicherer. Aber dann kann man die Schaltung nicht in bestehenden 5V-Systemen benutzen. Mhhh, andererseits kann man ja in dem Fall auch direkt hinter den Spannungsregler gehen. Okay, dann vielleicht wirklich Diode und Spannungsregler. Ich denke an eine Hohlsteckerbuchse, da kann man dann tolle und nicht so tolle Steckernetzteile anschließen.


    > Falls Du irgendwelche Probleme haben solltest mit Deiner CPU-Emulation


    Vielen Dank für das Angebot. Ich habe zwei Vorlagen in ARM-Assembler, die helfen mir im Zweifelsfall weiter.


    > Auch wenn's schon diverse ausgereifte Konkurrenz-Projekte gibt
    > was eigenes is' was eigenes !


    Genau, es gibt ja auch schon viele Demos, trotzdem kommen immernoch neue raus :-) Aber ganz zum Selbstzweck soll's ja auch nicht sein.


    > Ich bin auf jeden Fall schon mal gespannt, wie's weitergeht.


    Momentan bastle ich an einem ROM-Image mit Testcases. Seit der letzten Änderung an der CPU-Emulation weiß ich, wie schnell man die kaputtmachen kann. Ninja von The Dreams hat mir netterweise mit ein paar Scripts geholfen, die 6502 Test Suite von Wolfgang Lorenz zu konvertieren. Ein bisschen muss ich noch ändern. Selbstmodifizierender Code läuft aus dem ROM einfach nicht so prickelnd.


    > Wenn du daran denkst den Burst Transfer zu unterstützen,
    > dann sollte der SRQ (Takt) und Data auf ein 8 Bit Schieberegister
    > geführt werden.


    Stimmt, das ist etwas eng, wenn man nebenher noch einen Prozessor emuliert. Kann man dafür den I2C-Controller oder was auch immer missbrauchen? Momentan denke ich wirklich nur an eine 1541, aber wenn die Hardware auch die Burst-Sachen der 1571 und 1581 könnte, wäre das sicher nicht verkehrt. Ich nehme an, die SRQ-Leitung wird auch bidirektional benutzt?


    Danke und Gruß
    Thomas

    Zitat von skoe

    Stimmt, das ist etwas eng, wenn man nebenher noch einen Prozessor emuliert. Kann man dafür den I2C-Controller oder was auch immer missbrauchen? Momentan denke ich wirklich nur an eine 1541, aber wenn die Hardware auch die Burst-Sachen der 1571 und 1581 könnte, wäre das sicher nicht verkehrt. Ich nehme an, die SRQ-Leitung wird auch bidirektional benutzt?


    Nein TWI bzw. I2C geht nit, leider. SPI würde gehen. Auch der universal serial vom Tiny geht, habe schon daran gedacht einen Tiny zusätzlich nur wegen dem Burst einzusetzen. Ein Tiny ist billiger als dieses 745xx irgendwas Schieberegister ...


    Bidirektional ja. Aber beim Senden hast du kein Problem. Erstens muss das Signal nicht frequenzgenau sein und zweitens kann es auch beliebig langsam sein. Außerdem sind 2µs für eine moderne CPU auch kein Problem ...


    Beim Empfang auch nicht, wenn du NUR das tust. Ich habe beim Atmega 644 den Pin Change Interrupt "mißbraucht", sogar der ist manchmal zu langsam (außer man schaltet alle Interrupts aus), wenn gerade andere Interrupts laufen. Aber man kriegt zumindest mit, daß da was war ...

    @ Diddl


    Das mit dem Burst klingt wirklich interessant, wieder was dazugelernt. ;)



    @ skoe


    Ich habe mir die 1541-Schaltung jetzt mal angeschaut, und wenn ich heute nicht allzu sauerstoffarm geschlafen habe (ausgeschlossen ist das ja nicht), sieht es so aus, als wenn sich das mit einem NAND-Gatter so nicht ganz original verhalten würde.


    Ich habe das zum besseren Verständnis mal aufgelistet:


    Open1541
    -------------------------------------
    ATN_in (0) & P0.29 (0) = Data_out (1)
    ATN_in (0) & P0.29 (1) = Data_out (1)
    ATN_in (1) & P0.29 (0) = Data_out (1)
    ATN_in (1) & P0.29 (1) = Data_out (0)



    Original 1541
    --------------------------------------
    ATN_in (0) & ATN_A (0) = Data_out (0)
    ATN_in (0) & ATN_A (1) = Data_out (1)
    ATN_in (1) & ATN_A (0) = Data_out (1)
    ATN_in (1) & ATN_A (1) = Data_out (0)


    Um Data_out auf LO zu bekommen (falls ATN_in u. ATN_A (also Dein P0.29) mal gleichzeitig LO sein sollten), müßte man schon P0.27 auf HI setzen. Das würde allerdings 'ne dauerhafte Abfrage erfordern, und das wolltest Du doch eigentlich vermeiden, oder ?
    Aber wer weiß, vielleicht kommt dieser Zustand in der Praxis ja auch gar nicht vor. :roll:

    Ihr habt recht, das stimmt so einfach nicht. Allerdings muss ich zu meiner Ehrenrettung sagen, dass ich den Stromlauf der 1581 als Vorlage genommen hatte. Und dort ist ein NAND verwendet. Bei genauerem Hinsehen merke ich jetzt aber, das /ATN negiert wird, bevor es zum NAND kommt (siehe 1581 Service Manual, U7, U9). Also auch damit stimmt meine Schaltung nicht überein - da hat bei mir also der Sauerstoff gefehlt - grrrrr.


    1581
    -------------------------------------
    /ATN (0) & ATNACK (0) = Data_out (1)
    /ATN (0) & ATNACK (1) = Data_out (0)
    /ATN (1) & ATNACK (0) = Data_out (1)
    /ATN (1) & ATNACK (1) = Data_out (1)


    Open1541 (momentan)
    -------------------------------------
    ATN_in (0) & P0.29 (0) = Data_out (1)
    ATN_in (0) & P0.29 (1) = Data_out (1)
    ATN_in (1) & P0.29 (0) = Data_out (1)
    ATN_in (1) & P0.29 (1) = Data_out (0)


    Wenn man das freie Gatter zum Negieren von /ATN benutzen würde, würde es mit der 1581 überein stimmen. Nun zur 1541:


    Original 1541
    --------------------------------------
    ATN_in (0) & ATN_A (0) = Data_out (0)
    ATN_in (0) & ATN_A (1) = Data_out (1)
    ATN_in (1) & ATN_A (0) = Data_out (1)
    ATN_in (1) & ATN_A (1) = Data_out (0)


    Hab's nochmal geprüft, das stimmt so.


    Warum ist das bei der 1541 anders? Die Logik der 1581 schien mir inhaltlich plausibel zu sein. Vielleicht versteht man das mit den ROM-Listings? Jetzt muss ich mir überlegen, ob man das immernoch mit _einem_ 0,15 Euro IC hinbekommt. Braucht ja auch OC. Oder ob das 1541 ROM auch mit der Logik der 1581 funktioniert? Gibt's bei der 1541 an der Stelle unterschiede? Mist, sieht man nicht, ist in einem schwarzen Käferchen. ATN_A dürfte übrigens negiert sein, dass kommt ja aus Software. Wenn alle Stricke reißen, muss es halt doch mit Software gehen.


    Diddl: Wegen SPI gucke ich mal. Danke für den Hinweis.

    Zitat von skoe

    Diddl: Wegen SPI gucke ich mal. Danke für den Hinweis.


    Versteif dich nicht zu sehr aufs SPI. Offen gesagt hatte ich vor kurzem noch wenig Ahnung von SPI. Ich habe mir nur das SPI des Atmega 644 genauer angesehen, mit DEM wäre es möglich.


    Eigentlich ist es ganz simpel. Es braucht nur ein Schieberegister das von SRQ getaktet wird. Bei jedem low->high wird der Zustand der Data Leitung ins Schieberegister geschoben. Immer nach 8 Takten wird der Inhalt des Schieberegister in ein Latch geschoben. So funktioniert das im CIA.


    Das mit dem Latch braucht es zum Glück nicht unbedingt. Denn da gibt es immer ein Handshake mit der Clock Leitung nach jedem Byte. Der Empfänger quittiert also den Empfang eines Bytes. Also kommt sowieso immer nur ein Byte an.

    Mal 'ne ganz ketzerische Frage skoe:


    Warum willst Du den MC nur mit 10 MHz takten ? Bei einem Zyklus pro (ARM) Befehl hättest Du dann ja max. 10 Zyklen Zeit um einen 6502-Code - sowie die Peripherie - zu emulieren. Wird das nicht ein bisschen knapp ?
    Was spricht gegen einen höheren Takt (naja, außer die dadurch bedingte höhere Stromaufnahme) ?


    Das Ding'n hat doch eine max. Clockrate von 60 MHz (die braucht man ja nicht unbedingt ausreizen).
    Dann könnte man doch wahrscheinlich locker 'Data_out' nebenbei noch verwalten, und man hätte sogar noch Zeit den MC Kaffee kochen zu lassen, die Spülmaschine zu steuern, das Haus abzusichern, für 'nen C64-Emulator, usw. :D.

    Zitat

    Warum willst Du den MC nur mit 10 MHz takten?


    Ich musste erst einen Moment darüber nachdenken, wie Du darauf kommst. Als Antwort reichen vermutlich die drei Buchstaben: PLL ;-)


    Also, er läuft mit 60 MHz. So richtig viel Kaffe kann er im momentanen Design aber nicht mehr nebenbei kochen. Das hatten wir weiter vorn im Thread. Nochmal ganz kurz zusammengefasst:


    Einen 6502 im Allgemeinen kann man sicher auch einem AVR, ARM o.ä. mit wesentlich weniger als 10 MHz gut emulieren. Muss er aber _nach außen_ zyklengenau sein, also Richtung I/O, braucht man vielleicht etwas mehr. Schafft man wahrscheinlich auch noch mit einem AVR mit 20 MHz.


    Aber hier kommt noch dazu, dass wir den 6502 und die VIAs quasi im Hintergrund emulieren und im Vordergrund das machen, was das Laufwerk sonst noch so zu tun hat. Damit das Design nicht zu kompliziert wird, läuft die Emulation deshalb im Timer-IRQ.


    Momentan braucht sie 30% bis 50% bei 60 MHz. Klingt viel, aber es gibt einige Bremsfaktoren
    - Waitstates beim Lesen aus dem Flash bei 60 MHz kann die auch der LPC Lese-Puffer nicht verbergen
    - IRQ Overhead. Ist beim ARM wegen der Banked Register erträglich, aber immenoch wesentlich
    - Code noch nicht im Idealzustand...


    Will übrigens auf 16 MHz Quartz umsteigen, damit bekomme ich genau 1 MHz für den 6502 und auch noch recht genau 115200 baud und ganz genau 1000000 baud. Ein Baudratenquartz würde das 1 MHz kaputt machen. Den ARM lasse ich dann bei 48 oder 64 MHz laufen, mal sehen.


    Gruß
    Thomas

    Jau - die 3 Buchstaben reichen wohl. :P


    Alles klar, an sowas wie PLL habe ich erstmal überhaupt nicht gedacht, ich kannte den 'LPC213X' vorher auch nicht. Habe mir heute nur mal so auf die Schnelle ein (sehr) oberflächliches Datenblatt reingetan.
    Ehrlich gesagt bin im diesem Thread auch ziemlich gut quer eingestiegen, deshalb habe ich auch nichts von irgendwelchen vorigen Überlegungen u. Ausführungen mitbekommen ---> Die volle Packung Schande über mich ! ! !

    Hätte mich auch stark gewundert, wenn Du Dir nicht von vorne herein schon das Maximum gönnen würdest.
    Und du hast recht, 30 - 50 % klingt wirklich viel, aber die Bremsfaktoren sind einleuchtend. Der MC erscheint mir dann auch nur sub-optimal zu sein, aber im Endeffekt wohl ausreichend.
    Auf jeden Fall müßtest Du dann in der Tat Rechzeit sparen, wo Du nur kannst.


    Die Emulation würde ich auch im Timer-IRQ laufen lassen, damit macht man nichts falsch (zumindest dann nicht, wenn die IRQ-Ausführung nicht durch irgendwelche Umstände verzögert werden kann).


    Schade, dann wird's ja nix mit dem Kaffee... :hammer:

    > Die volle Packung Schande über mich ! ! !
    Üüüüberhaupt kein Problem!

    >Der MC erscheint mir dann auch nur sub-optimal zu sein, aber im Endeffekt wohl ausreichend.
    In der gleichen Preisklasse hatte ich mit auch den AT91SAM7 und den AVR32 angesehen. Der SAM7 ist aus dem Flash noch etwas langsamer, da ohne Cache, die Timer sind nicht so komfortabel - hat aber mehr RAM zum gleichen Preis. Der AVR32 kommt mit einer schönen Entwicklungsumgebung, hat einen schönen Befehlssatz, aber leider keine Banked Register, d.h. im IRQ muss man alle benutzten auf dem Stack sichern. Auch ist der AVR32 mit Flash noch etwas schwer zu beschaffen.


    >ein (sehr) oberflächliches Datenblatt
    Es gibt ein Datenblatt, wo nur ein paar grundlegende Dinge und die elektrischen Werte drinstehen. Richtung Features und Software ist das User Manual UM10120-1.PDF das richtige Dokument. Und dann gibt's noch ne Handvoll Application Notes und natürlich ein Errata Sheet.


    Interessant wäre ein AVR32 auch wg. USB OTG (USB Stick statt SD-Card?). Vielleicht steige ich nach dem ersten Prototypen ja doch noch um, aber jetzt kein guter Zeitpunkt dafür.


    > Die Emulation würde ich auch im Timer-IRQ laufen lassen, damit macht man nichts falsch
    Außer Rechenzeit verbraten ;-)


    > zumindest dann nicht, wenn die IRQ-Ausführung nicht durch irgendwelche Umstände verzögert werden kann
    Kann sie, aber nur um ein paar Zyklen. Den Timer-IRQ habe ich in den FIQ = höchste Priorität gelegt. Die Zugriffe auf I/O glaube ich trotzdem (ARM)-zyklengenau hinzubekommen (Timer Match Output oder Busy Wait).


    > Schade, dann wird's ja nix mit dem Kaffee...
    Möchtest Du nicht am Schaltplan weitermachen? Dann gebe ich Dir mal einen Kaffee aus ;-)


    So, jetzt muss ich mal mein CMP fixen. Die Test Suite hat ausgespuckt, dass was mit den Flags nicht stimmt. Komisch, hatte ich doch getestet...


    Das original ROM ist übrigens auch schonmal bis zum ersten Zugriff auf die VIAs gelaufen. Die stehen dann also als nächstes auf dem Plan. Timer und so...

    @ skoe


    Leider habe ich bis jetzt keine Zeit gefunden, Dir zu antworten.
    Nicht das Du noch denkst, ich wolle nicht mehr mit Dir reden... ;-)


    Zitat von skoe


    In der gleichen Preisklasse hatte ich mir auch den AT91SAM7 und den AVR32 angesehen. Der SAM7 ist aus dem Flash noch etwas langsamer, da ohne Cache, die Timer sind nicht so komfortabel - hat aber mehr RAM zum gleichen Preis.


    Der AVR32 kommt mit einer schönen Entwicklungsumgebung, hat einen schönen Befehlssatz, aber leider keine Banked Register, d.h. im IRQ muss man alle benutzten auf dem Stack sichern. Auch ist der AVR32 mit Flash noch etwas schwer zu beschaffen.


    Habe mir inzwischen einige Datenblätter runtergezogen, aber leider noch keine Zeit gehabt, mir die mal genauer reinzupacken. Jeder von den Dingern hat scheinbar so seine Vor- und Nachteile. Das Beste wird's wirklich sein, Du machst erstmal mit dem LPC213X weiter, der sollte eigentlich dafür ausreichen.


    Zitat von skoe


    Interessant wäre ein AVR32 auch wg. USB OTG (USB Stick statt SD-Card?). Vielleicht steige ich nach dem ersten Prototypen ja doch noch um, aber jetzt ist kein guter Zeitpunkt dafür.


    Wenn man so'n USB-Stick als Datenträger verwenden könnte, wäre das in der Tat schon 'n schönes Ding. Wenn erstmal alles so weit läuft, könntest Du vielleicht immer noch irgenwann mal zum AVR32, oder evtl. auch zum nächst größeren LPC2xxx -Typen, wechseln, der dann auch USB unterstützt.
    Muss aber auch nicht sein, SD-Karten sind auch nicht so übel. ;)


    Zitat von skoe


    Möchtest Du nicht am Schaltplan weitermachen? Dann gebe ich Dir mal einen Kaffee aus ;-)


    Ich werde nach erfolgreichem Abschluß mal 'ne Tasse voll davon auf Dein Wohl trinken. :->

    Aber auf Deine Frage zurückzukommen - Ja, warum nicht ?
    Das Problem ist nur, dass ich erst so in ungefähr 2 Mon. dafür richtig Zeit hätte. Ich hoffe mal, dass ich bis dahin mit meinen eigenen Projekten fertig bin. Naja, wenigstens mit einem davon, das wäre ja schon was...


    Zitat von skoe


    So, jetzt muss ich mal mein CMP fixen. Die Test Suite hat ausgespuckt, dass was mit den Flags nicht stimmt.
    Komisch, hatte ich doch getestet...
    Das original ROM ist übrigens auch schonmal bis zum ersten Zugriff auf die VIAs gelaufen.
    Die stehen dann also als nächstes auf dem Plan. Timer und so...


    Ich merke schon - es geht vorwärts. :)

    Wieso sind die AVR32 schwer zu beschaffen? Du meinst sicher die Chips, denn Platinen gibt es überall zu kleinem Geld. Bei manchen Dingen muß man sich schon überlegen ob man einen 2560 einsetzt, wenn man um ein paar Euro mehr schon einen AVR32 UC3A1512 haben kann ...



    Ich habe mir jetzt mal so eine Atmel AVR32 UC3A1512 Adapterplatinebestellt.

    > Du meinst sicher die Chips
    So isses. Für LPC gibt's sogar in Deutschland mehrere Quellen, beim AVR32 mit Flash sieht's etwas schwieriger aus. Aber das ändert sich sicher in den nächsten Monaten.


    Wahrscheinlich sollte das keine Aufforderung sein, den Controller in der open1541 zu wechseln. Falls doch:


    Ein Umstieg auf einen anderen Controller in der open1541 wäre _momentan_ reine Blindleitung ohne technischen oder preislichen Vorteil (auch wenn manche sich besser fühlen, wenn "Atmel" drauf steht). Der erste Prototyp wird definitiv mit SD-Karte laufen, weil des Pudels Kern die 1541-Emu ist, und nicht das Speichermedium. Dafür würde ich dann die Sourcen des sd2iec verwenden. USB ist eine Haufen Arbeit.


    Ein Wechsel zu einem anderen Controller in der gleichen Preisklasse hätte momentan sogar einige technische Nachteile, wie man im Thread weiter oben lesen kann (Stichworte: Banked Registers, Timer, DAC)


    Das alles soll nicht heißen, dass ich einen Controller-Wechsel machen würde, wenn es technische oder finanzielle Vorteile brächte. Hab ja gestern schon beschrieben, was mir am AVR32 gefällt. Die CPU-Emu wäre wahrscheinlich nach ein paar Tagen Arbeit (bei ca. 1 bis 2 h/d) portiert.


    Die Adapterplatine sieht gut aus. Damit kann man sicher komfortabel auf einem Breadboard oder Lochraster einsteigen.


    Du hast ja schon mitbekommen, dass ich genau wie Du nur begrenzt Zeit habe. Deswegen will ich wenigstens keine Umwege machen.


    @Camico
    Willkommen zurück. Ich glaube, der Zeitraum von zwei Monaten ist in diesem Projekt kein Problem :-)


    Wir können ja schonmal ein paar Gedanken sammeln, was noch alles für die Hardware zu tun ist. Ein paar stehen ja schon hier im Thread.


    Einen kaufbaren NXOR mit OC habe ich nicht gefunden. Also vielleicht doch einfach nur Treiber und das ACK in Software. Könnte man dann als 74HCTxx OC machen oder mit FETs wie im sd2iec. Vom Platz her nimmt es sich nicht sehr viel. Vermutlich ist ein 74HCTxx ein paar Cent günstiger.


    Kurzer Fortschrittsbericht: Um möglichst wenig gegen Windmühlen kämpfen zu müssen, wenn ich das/den (Grammatik, warum hast Du mir verlassen?!) 1541 ROM laufen lasse, hab ich in den letzten Tagen mehr Aufwand in automatisierte Tests gepackt. Dabei hab ich noch ein paar Fehler in der CPU-Emu gefunden. Momentan baue ich 6502-Breakpoint-Kommandos in das CLI ein, damit man später einfacher debuggen kann. Funktioniert schon halbwegs, aber wenn er einmal steht, will er nicht mehr loslaufen :-/ Das schaffe ich hoffentlich heute abend.


    Gruß,
    Thomas

    Cool da geht ja richtig was weiter. :juhu:


    Bin gespannt wie genau die Zyklusgenaue Emulation dann wirklich arbeitet. Bei den sensiblen Turbo Routinen wird es sich dann zeigen. Ich drück dir auf alle Fälle die Daumen dass alles wie erhofft funktioniert.



    Wie schaut es mit einer 1571 oder 1581 aus? Der Burstmode verlangt fast ein CIA oder zumindest ein Schieberegister. Oder bekommt man das eventuell auch als Emulation hin?

    Zitat

    Bin gespannt wie genau die Zyklusgenaue Emulation dann wirklich arbeitet.


    Zumindest im Konzept sollte es klappen.... Dank Unseen bin ich mir auch der Sache mit dem zusätzlichen Zyklus in den VIA-Ports bewusst. Die soll wohl z.B. im DTV vergessen worden sein. Aber der Teufel liegt bekanntlich im Detail, es ist noch ein langer Weg.


    Die VIA Timer sind bald dran... das wird knifflig.


    Zitat

    Wie schaut es mit einer 1571 oder 1581 aus?


    Um mich nicht in Details zu verlieren, hab ich mich entschieden, mich erstmal ausschließlich um die 1541 zu kümmern. Bei der Pin-Belegung sollten wir den anderen SPI freihalten (P0.17-P0.20), falls man das VIA/CIA Schieberegister tatsächlich mal damit umsetzen kann/möchte.


    Sollte ich eigentlich erstmal den 1541-I oder II ROM nehmen? Kann da jemand aus technischer Sicht was empfehlen?