W65C02S-Einplatinencomputer

Es gibt 295 Antworten in diesem Thema, welches 49.574 mal aufgerufen wurde. Der letzte Beitrag (25. Dezember 2012 um 19:58) ist von norbi40.

  • Ich würde als Designziel in die Richtung von max 4-5MHz denken wenn Bauteile und Logik bezahlbar bleiben sollen. Einen Prototyp erstmal mit 2 MHz testen. Optimieren kann man später immer noch.

    Mir würden 4Mhz reichen. Mit zwei FlipFlop kommt man dann leicht auf einstellbare 2 und 1Mhz.

    Eagle kosten in der Hobbylizenz (neuerdings ?) über 40€ mehr. Ich habe mir KiCad mal angeschaut. So langsam komme ich damit klar und habe die Eagle-Libs für KiCad gefunden: Bitte melde dich an, um diesen Link zu sehen.
    Bei den 65*-Bauteilen musste ich den Footprint anpassen. Abgesehen vom Komfortverlust und Eingewöhnung, sieht das nicht so schlecht aus. Habe erstmal nur ein bisschen experimentiert.
    Da werde ich mich noch einarbeiten müssen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |


  • Flash finde ich gerade nicht in 5V-kompatibel und flott, aber Ram wäre kein Problem: Bitte melde dich an, um diesen Link zu sehen. ;)

    Ein 512KBx8 SRAM mit 55ns gibts bei Reichelt unter der Best. Nr. 628512-55 für 3.65 Euro. Das mit dem RAM passt also schonmal. Wenn es beim EPROM/Flash knapp wird kann man _CS auf GND legen und über _OE steuern, bringt ein paar ns, weil dann interne Dekodierung im ROM und Freigabe der Ausgangsleitungen parallel laufen, aber leider auch mehr Stromverbrauch.

    Flash... viel zu gross und PLCC, aber 5V und 55ns schnell: AM 29F010-55 bei Reichelt für 1,90.


  • Ja, das hat was. Ich würde den I/O-Bereich mit zwei 138ern dekodieren. Dann hat man acht Adressen für I/O und sieben größere Bereiche für externe Erweiterungen. Dann könnte man einen 74*273 für die oberen RAM-Leitungen verwenden.
    Ich würde gesamt einen VIA einplanen und ausreichend Erweiterungs-Slots. Dann kann immer noch eine I/O-Karte angesteckt werden, wenn jemand mehr braucht.

    Insgesamt ist das Banking mit einem VIA vorallem eines: teuer. Ein VIA kostet bei Mouser 5,73€. Lösungen mit CMOS-Logik sind dagegen sehr günstig. Die paar Logikchips kosten zusammen vielleicht 2€. Ich überdenke gerade eine geeignete Lösungsmöglichkeit.


    Auf 6502-Basis oder eine andere CPU wie 68000 oder Z80? Letztere sind beim Timing deutlich entspannter und 5 MHz kein wirkliches Problem. Der 6502 mit seinem Buszugriff in jedem Zyklus und dann noch nur die Hälfte dieses Zyklus benutzend stellt schon bei moderaten Frequenzen ziemliche Anforderungen.

    Beim C64 kein Problem, ein halber Zyklus sind immer noch um 500ns. Damit kann man Logik problemlos kaskadieren, langsame PLAs einsetzen und DRAMs mit 200ns verbauen. Bei 4 MHz sind es auf einmal nur noch 125ns für alles incl. Laufzeit der Logik.

    Die SRAM Chips sind bei 55ns und der (viel zu große) EEPROM auch. (Bitte melde dich an, um diesen Link zu sehen.)

    Da ist also selbst bei 8 MHz noch etwas Spiel. Ich würde für den Anfang vielleicht auf 5 MHz gehen, dann bräuchte man auch nur einen Quarzoszillator für AVR und 65C02 (20MHz für AVR und 20MHz mit 4fachem Teilungsfaktor auf 5 MHz.)

    Gerrit: PLCC ist garkein Problem, weil das einerseits Platz spart, und andererseits gibt es auch dafür Sockel.
    Die billigeren Platinenpreise machen die Kosten vom Sockel wett.

    @all: Stromverbrauch spielt kaum eine Rolle, da die 65C02 und 65C22 kaum Strom verbrauchen, da sie in CMOS ausgeführt sind. Das ist, im Gegensatz zu NMOS, sehr sparsam.

    MfG.
    crasbe

  • Da ist also selbst bei 8 MHz noch etwas Spiel. Ich würde für den Anfang vielleicht auf 5 MHz gehen, dann bräuchte man auch nur einen Quarzoszillator für AVR und 65C02 (20MHz für AVR und 20MHz mit 4fachem Teilungsfaktor auf 5 MHz.)

    Vergiss die Gatterlaufzeiten der Logikbausteine nicht! 8 MHz bedeutet 62,5 ns pro Flanke, das wird selbst mit den schnellen 55ns-Chips nicht zuverlässig funktionieren, 7,5 ns Logik-Overhead sind zu wenig! Wenn es wirklich die 55ns-Chips werden, dann sind 5 MHz aber drin und auch stabil. Bei der Teilung könnte man dann evtl. auch einen Kompatibilitätsmodus (2,5 MHz) vorsehen, falls jemand langsameren Speicher verwenden möchte. ;)

    @all: Stromverbrauch spielt kaum eine Rolle, da die 65C02 und 65C22 kaum Strom verbrauchen, da sie in CMOS ausgeführt sind. Das ist, im Gegensatz zu NMOS, sehr sparsam.

    Dafür ist der Verbrauch aber auch direkt von der Taktfrequenz abhängig. ;) Im Gegensatz zu NMOS aber ein Witz, da haste Recht.


  • Insgesamt ist das Banking mit einem VIA vorallem eines: teuer. Ein VIA kostet bei Mouser 5,73€. Lösungen mit CMOS-Logik sind dagegen sehr günstig. Die paar Logikchips kosten zusammen vielleicht 2€. Ich überdenke gerade eine geeignete Lösungsmöglichkeit.

    Wenn du die aktuelle Bank nicht auslesen können musst (kann man sich schliesslich in der Zero-Page merken), dann reicht als Register fürs Banking ein 74HCT574 plus ein OR-Gatter (_CS und R/_W beide low). Da man nur 4 Bits fürs Banking braucht sind dann noch weitere 4 Bits für anderes übrig. Billiger gehts nicht.

  • Die Idee mit den 16KiB Abschnitten gefällt mir.
    In den ersten Abschnitt mit der Zeropage und dem Stackpointer würde ich die Chips legen, weil man hier keine vollen 15KiB braucht, der mittlere, 32KiB große Abschnitt würde permanent auf RAM liegen und von evtl. angesteckten Erweiterungen beeinflusst werden, und die letzten 16KiB sind auf ROM gelegt.
    Den ersten und den letzten Abschnitt kann man dann noch auf RAM umschalten.

    Das ganze in Logik ausgedrückt:
    Zeropage: 2 Logikchips: A0-A9 sind direkt mit dem RAM verbunden, A10-A15 werden mit einem 74xx688 mit GND verglichen und _CS von RAM liegt auf GND.
    R/_W wird mit dem Ausgang von dem 74xx688 mit ein paar NORs ([(a NOR a) NOR b] NOR [(a NOR a) NOR b] => Implies) zu /RE und noch mehr NORs ((a NOR b) NOR (a NOR b) = OR) für /WE aufgerennt. Die ganzen NORs passen in einen 74xx02, also kein TTL-Grab.

    Banking ansich:
    $0000-$3FFF: 1. Bank: A14 NOR A15 = 1
    $4000-$7FFF: 2. Bank: A15 NOR A15 = 1
    $8000-$BFFF: 3. Bank: A14 NOR (A15 NOR A15) = 1
    $C000-$FFFF: 4. Bank: (A14 NOR A14) NOR (A15 NOR A15) = 1
    Für den NOR-Chip bietet sich ein 74xx02 an.

    Das kann man dann mit z.B. einem Schieberegister und einem 74xx08 Baustein an die Chips weiterleiten.
    Die Ansteuerung für das Schieberegister könnte man in die Zeropage legen, weil die ja immer bestehen bleibt.

    Kann nochmal jemand drüber sehen, ob ich irgendetwas übersehen habe?
    In den nächsten Tagen werde ich wohl nicht so aktiv sein, weil mich die Grippe fies erwischt hat.

    Nochmals vielen Dank für eure tatkräftige Unterstützung :thumbup:

    MfG.
    crasbe

  • Die Idee mit den 16KiB Abschnitten gefällt mir.
    In den ersten Abschnitt mit der Zeropage und dem Stackpointer würde ich die Chips legen, weil man hier keine vollen 15KiB braucht,

    Nein, eben nicht. Die RAM-Bank liegt am Stück ab $0000 und hat 32KB, alles andere macht deutlich mehr Aufwand schon bei der Selektion. I/O legt man nie in die Zero-Page.

    Die von mir vorgeschlagene und komplett ausdekodierte Map sieht so aus:

    $0000-$03FF (immer dieselbe RAM-Bank wegen Zero-Page und Stack)
    $0400-$7FFF (Umschaltbare RAM-Bank)
    $8000-$BFFF (I/O-Bereich, ausdekodiert auf 16 x 1KB mittels 2x 74xx138 und 1 Inverter )
    $C000-$FFFF ROM

    Aufwand an TTLs dafür incl. Banking für RAM: 1x 74LS688, 1x 74LS08, 2x 74LS00 und 2x74LS138. Teile eines 74LS00 werden als Inverter missbraucht. Falls das Banking nicht über einen VIA-Port stattfinden soll kommt noch 1x 74LS574 und 1x 74LS32 dazu.

    Umgeschaltet wird immer nur das RAM, ROM und I/O sind immer gleich, es gibt keinen Grund auch hier mit Banking zu arbeiten. Es ist ein Kleinrechner, da sollten 16 KB ROM mehr als ausreichen. Commodore hat in sowas ein komplettes BASIC incl. Screen-Editor bzw. die Steuerung der 1541 untergebracht.

    Zitat


    Zeropage: 2 Logikchips: A0-A9 sind direkt mit dem RAM verbunden, A10-A15 werden mit einem 74xx688 mit GND verglichen und _CS von RAM liegt auf GND.

    Das tut man nicht. _CS legt man nur fest auf GND wenn es unbedingt sein muss. Sonst ist der Chip die ganze Zeit aktiv und braucht mehr Strom. Bei CMOS nicht so wichtig, aber muss ja nicht sein.

    Zitat


    R/_W wird mit dem Ausgang von dem 74xx688 mit ein paar NORs ([(a NOR a) NOR b] NOR [(a NOR a) NOR b] => Implies) zu /RE und noch mehr NORs ((a NOR b) NOR (a NOR b) = OR) für /WE aufgerennt. Die ganzen NORs passen in einen 74xx02, also kein TTL-Grab.

    Deutlich mehr Aufwand für keinen zusätzlichen Vorteil gegenüber _CS-RAM = A15. Nebenbei hast du die Erzeugung von _WE-RAM aus R/_W und PHI2 vergessen.

    Du brauchst aber nicht HIGH als Ausgang sondern LOW wenn der Ausgang als _CS benutzt werden soll. Abgesehen davon ist $C000-$FFFF für das ROM einfacher mit einem (A14 NAND A15) zu erreichen. Den Rest der NAND brauchst du sowieso für R/_W und PHI2.

    Zitat


    Das kann man dann mit z.B. einem Schieberegister und einem 74xx08 Baustein an die Chips weiterleiten.
    Die Ansteuerung für das Schieberegister könnte man in die Zeropage legen, weil die ja immer bestehen bleibt.

    Das Ausdekodieren des ganzen I/O in der Zeropage (für die man sonst andere Verwendung hat!) frisst dann wieder einiges an TTL. Keine gute Idee, Zeropage und Stack sind 100% RAM, alles andere bringt keinen Vorteil, nur Aufwand an Logik.

  • Nein, eben nicht. Die RAM-Bank liegt am Stück ab $0000 und hat 32KB, alles andere macht deutlich mehr Aufwand schon bei der Selektion. I/O legt man nie in die Zero-Page.

    Die von mir vorgeschlagene und komplett ausdekodierte Map sieht so aus:

    $0000-$03FF (immer dieselbe RAM-Bank wegen Zero-Page und Stack)
    $0400-$7FFF (Umschaltbare RAM-Bank)
    $8000-$BFFF (I/O-Bereich, ausdekodiert auf 16 x 1KB mittels 2x 74xx138 und 1 Inverter )
    $C000-$FFFF ROM

    Aufwand an TTLs dafür incl. Banking für RAM: 1x 74LS688, 1x 74LS08, 2x 74LS00 und 2x74LS138. Teile eines 74LS00 werden als Inverter missbraucht. Falls das Banking nicht über einen VIA-Port stattfinden soll kommt noch 1x 74LS574 und 1x 74LS32 dazu.

    Umgeschaltet wird immer nur das RAM, ROM und I/O sind immer gleich, es gibt keinen Grund auch hier mit Banking zu arbeiten. Es ist ein Kleinrechner, da sollten 16 KB ROM mehr als ausreichen. Commodore hat in sowas ein komplettes BASIC incl. Screen-Editor bzw. die Steuerung der 1541 untergebracht.


    Ich wüsste nicht, warum man das Banking jetzt wieder komplett über den Haufen werfen soll?
    Es sollen, wie ich bereits schrieb, 64KiB RAM benutzt werden. Die 1541 kann man kaum damit vergleichen, weil niemand eine 1541 miiit 4KiB RAM als Programmierplattform nehmen will. 64KiB RAM sind durchaus ein Luxus, den wir uns leisten können.
    Das ROM fest nach $C000-$FFFF halte ich für eine denkbar schlechte Variante, weil man dann z.B. die Interruptvektoren nicht verändern kann.

    Den IO-Bereich wollte ich nicht IN die Zeropage legen, sondern DAHINTER. 15KiB sind für I/O-Sachen mehr als ausreichend.

    Zitat

    Deutlich mehr Aufwand für keinen zusätzlichen Vorteil gegenüber _CS-RAM = A15. Nebenbei hast du die Erzeugung von _WE-RAM aus R/_W und PHI2 vergessen.


    Tatsächlich. Das ist mir irgendwie entgangen...

    Zitat

    Du brauchst aber nicht HIGH als Ausgang sondern LOW wenn der Ausgang als _CS benutzt werden soll. Abgesehen davon ist $C000-$FFFF für das ROM einfacher mit einem (A14 NAND A15) zu erreichen. Den Rest der NAND brauchst du sowieso für R/_W und PHI2.


    Stimmt, NAND ist natürlich dafür viel besser geeignet.

    Zitat

    Das Ausdekodieren des ganzen I/O in der Zeropage (für die man sonst andere Verwendung hat!) frisst dann wieder einiges an TTL. Keine gute Idee, Zeropage und Stack sind 100% RAM, alles andere bringt keinen Vorteil, nur Aufwand an Logik.


    Naja gut, aber 8 Bit Zeropage wird man für Banking wohl über haben.
    So viel Logik wird das decodieren auch nicht mehr brauchen.

    MfG.
    crasbe


  • Ich wüsste nicht, warum man das Banking jetzt wieder komplett über den Haufen werfen soll?

    Das Banking ist nicht über den Haufen geworfen. Ich hatte eine Variante vorgeschlagen die mit wenig Hardware implementieren ist, die die RAM-Bank am Stück ohne Löcher liefert, Zeropage und Stack in allen Bänken liefert und trotzdem 32 KB RAM pro Bank hat. Wobei das erste KB immer dasselbe ist, also Zeropage, Stack und 512 Bytes RAM enthält. Du hast also pro Bank 31 KB frei. Bei Verwendung eines 628512 SRAM sind das 16 Bänke. Falls die 512 Bytes nicht reichen ist es trivial (Ein Jumper im Layout) den festen Block auf 2 KB zu erweitern (1.5KB nach Zeropage und Stack). Da passt Code für Banking und Interrupts problemlos rein.

    Zitat


    Es sollen, wie ich bereits schrieb, 64KiB RAM benutzt werden.

    Das ist mit einem 6502 nicht zu machen wenn du nicht auch noch das ROM umschalten willst. Das verkompliziert die Sache unnötig. Vergiss für dieses Projekt den Aufbau des C64 (an dem scheinst du dich zu orientieren) und überleg was man bei einem einfach aufzubauenden Rechner wirklich braucht und wieviel RAM es am Stück sein darf. Ich halte 32 KB pro Speicherbank für vollkommen ausreichend.

    Zitat


    Die 1541 kann man kaum damit vergleichen, weil niemand eine 1541 miiit 4KiB RAM als Programmierplattform nehmen will.

    Ich bezog mich hier auf das ROM, nicht auf das RAM und warum ich 16 KB ROM für vollkommen ausreichend halte.

    Zitat


    Das ROM fest nach $C000-$FFFF halte ich für eine denkbar schlechte Variante, weil man dann z.B. die Interruptvektoren nicht verändern kann.

    Aha... und dein RESET-Vector? Der sollte beim RESET vorhanden sein. Wenn du dir wegen der IRQ/NMI-Vectoren Sorgen machst, das ist einfachst zu lösen. Im ROM selbst steht nur eine kurze Routine (Register sichern z.B. und dann ein JMP($RAM-adresse im festen Block) ). So wie das bei den CBM-Rechnern auch gemacht wurde. Schon stört das feste ROM nicht mehr. Die RESET-Routine stellt hier als Ziel jeweils ein Ziel ein welches einen IRQ sauber beendet. Dein Programm kann diesen Vector jederzeit anpassen.

    Zitat


    Den IO-Bereich wollte ich nicht IN die Zeropage legen, sondern DAHINTER. 15KiB sind für I/O-Sachen mehr als ausreichend.

    Die Schaltung um hier ein Loch ins RAM zu stanzen ist nicht ganz ohne und vollkommen sinnfrei wenn man I/O nach $8000-BFFF legt und das RAM ab $0000 beginnen lässt.

    Zitat


    Naja gut, aber 8 Bit Zeropage wird man für Banking wohl über haben.
    So viel Logik wird das decodieren auch nicht mehr brauchen.

    Das sagt sich so einfach... Formulier das mal aus. Die von mir vorgeschlagene Speichermap hat ihre Gründe, einer davon die Einfachheit der Dekodierung der Bereiche und die Vermeidung der Fragmentierung des RAMs.

    Das der 6510 sein IO-Register bei $00 und $01 hat bedeutet nicht, dass das einfach zu dekodieren war, ist es nämlich nicht, auf dem CPU-Die ist der Aufwand für den Dekoder aber irrelevant. Der Grund war das das Register dort nicht stört als wenn man es an eine beliebige andere Adresse legt die, je nach System, vielleicht mitten im RAM liegt.

  • Das ROM fest nach $C000-$FFFF halte ich für eine denkbar schlechte Variante, weil man dann z.B. die Interruptvektoren nicht verändern kann.

    Doch. Kennst Du Dich ein bisschen mit IRQ-Programmierung aus ? - Die CPU springt über den IRQ-Vector im ROM eine Routine an, die letztendlich per JMP($irq) den ROM-eigenen Job-Code abarbeitet. Wenn man die Routine umbiegen möchte, muss man nur per SEI den IRQ sperren, danach #<$irq bzw. #>$irq auf die neue Quelle zeigen lassen (und CLI). Evtl. muss noch den alten Job-Code per JMP anspringen. Die Adresse an $fffe muss man nie ändern.

    Ich fand die Ideen von Gerrit sehr schlüssig. Bin schon sehr auf Deinen ersten Entwurf gespannt.

    Edit: Bitte melde dich an, um diesen Link zu sehen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Moin,

    jetzt mische ich mich auch mal ein :wink:

    also ihr wollt einen neuen rechner bauen, hab' ich das bis jetzt richtig verstanden? (der thread ist sehr lang und das sollte evtl. auch im titel stehen, wenn es denn so ist).

    um etwas flexibler zu sein, koenntest du z.B. einen I/O baustein (á la 8255/82C55) in einen der i/o bereiche packen und darueber so einiges schalten, beispielhaft:
    - 8 bit fuer rom banking
    - 8 bit fuer i/o (joystick/...)
    - 8 bits (einzeln setz/loesch bar)
    -- ram banking (oder dafuer ein 8bit register mit noch mehr inhalt)
    -- banking der ZP (auch ein nettes feature)

    soll das rom fest verbaut, oder als cartridge steckbar sein?

  • Zitat

    -- banking der ZP (auch ein nettes feature)


    ich würde ja zeropage und stack bankbar machen - dann kann man recht komfortabel multitasking machen

  • um etwas flexibler zu sein, koenntest du z.B. einen I/O baustein (á la 8255/82C55) in einen der i/o bereiche packen und darueber so einiges schalten, beispielhaft:
    - 8 bit fuer rom banking
    - 8 bit fuer i/o (joystick/...)
    - 8 bits (einzeln setz/loesch bar)
    -- ram banking (oder dafuer ein 8bit register mit noch mehr inhalt)
    -- banking der ZP (auch ein nettes feature)

    Das meiste davon ist schon abgedeckt. Wobei der 8255 nicht wirklich taugt, er braucht mehr Anpassung der Steuersignale als der 6522 und kann die Ports nicht bitweise zwischen Ein- und Ausgang umschalten. Die urpsrüngliche Idee sah 2x 6522 und 1x 6551 oder anderen UART7ACIA vor.

    RAM-Banking ist schon enthalten. Nach Beschwerde, dass ein VIA-Port dafür zu 'teuer' sei hab ich die Anforderung auf einen 74xx574 plus ein NOR-Gatter (Ich hatte ein OR angegeben, aber der 74xx574 übernimmt bei LOW -> HIGH, also NOR von _CS und R/_W) für das Banking-Register geändert. Da man das nicht auslesen kann, muss der Inhalt in einem Byte im RAM gespeichert werden.

    Abgesehen von der Schwierigkeit der Implementation (der Stack muss schliesslich bleiben) halte ich ein Banking der Zeropage für keine gute Idee. Du brauchst etwas festes RAM für Daten und etwas festes RAM für Code. Für Daten und Vektoren bietet sich die ZP an, die 256 Bytes reichen sehr weit und man hat die schnellen Befehle zum Zugriff.

    Zitat


    soll das rom fest verbaut, oder als cartridge steckbar sein?

    Das ist eine reine Sockelfrage... Einige hier hätten gerne Flash. Mir würde ein EPROM mit Monitorprogramm reichen.

    Ich behaupte hier nicht, dass meine Designidee das nonplus-ultra ist, sie ist nur sparsam bei der Logik und damit den TTL-ICs, braucht keine GALs oder sonstige programmierbare Chips, bietet bis 512KB RAM in 16 Bänken a 32 KB (incl. 1 KB die in jeder Bank dasselbe sind und ZP und Stack enthalten) und hat noch jede Menge ausdekodierte I/O-Bereiche.


  • ich würde ja zeropage und stack bankbar machen - dann kann man recht komfortabel multitasking machen

    Wäre machbar (braucht einen 74LS257 statt dem 74LS08 im Banking), aber die Programmierung wird dann zum Albtraum. Auf einem 6502 finde ich das auch etwas Overkill, wenn ich Multitasking will, welches umschaltbare ZP und Stack braucht, dann nehme ich keinen 6502 mehr.

  • Hallo Gerrit,

    bitte fuehle dich nicht auf den shclips getreten. Ich hatte einfach ein paar vorschlaege gemacht, ich bin ja auch nicht so in der materie drin. Ich hatte den 8255 genommen, weil ich den kenne (von meinem "Multiprommer") und er dafuer tut - klar, andere koennen das besser :wink:

    Was ZP/Stack banking betrifft - das koennte eine nette option sein. Ich glaube dass man problemlos den stack mit umschalten kann, da ja bevor man zurueck gibt auch wieder die richtige ZP/Stack-Page hergestellt hat. Um das noch weiter zu vereinfachen: ein bit mit dem man schalten kann ob die ersten 1kb immer von bank 0 kommen oder mit gebankt werden (das sollte man [wie auch das "normale" banking] auslesen koennen) - aber wie gesagt, kein muss.

    Und da ich nicht glaube dass ich mir so eins baue (hab' eh' schon genug projekte) ist es nicht mal "fuer mich" sondern einfach nur nettgemeinte vorschlaege.

  • Hallo Gerrit,

    bitte fuehle dich nicht auf den shclips getreten.

    So schnell geht das nicht.

    Zitat


    Was ZP/Stack banking betrifft - das koennte eine nette option sein. Ich glaube dass man problemlos den stack mit umschalten kann, da ja bevor man zurueck gibt auch wieder die richtige ZP/Stack-Page hergestellt hat.

    Geht natürlich, man muss aber beim Umschalten auch an den Stackpointer denken!

    Zitat


    Um das noch weiter zu vereinfachen: ein bit mit dem man schalten kann ob die ersten 1kb immer von bank 0 kommen oder mit gebankt werden (das sollte man [wie auch das "normale" banking] auslesen koennen) - aber wie gesagt, kein muss.

    Das wird von der Schaltung her leider nicht einfacher sondern deutlich komplexer (1 74LS245, 1x OR , 1x Inverter) Man muss sich bei einem solchen Design immer überlegen wieweit man gehen will, nach oben ist alles offen. Wenn ich den erwähnten 74LS08 durch einen 74LS257 ersetze kann ich die Option des Umschaltens der Bank mit ZP und Stack offen halten. Die oberen 4 Bit des Bankingregisters (74LS574) enthalten dann die Bank der ZP/Stack. Beim RESET muss einer der ersten Befehle dort $00 reinschreiben. Damit hat man ohne zusätzliche Logik die Option offen es zu benutzen muss aber nicht. Bei Programmierung genug Aspirin bereithalten. :)

  • Mal ein Kommentar von 'aussen':
    ich finde es sogar interessant, wenn am Ende so manches Detail eher effizient als maximal flexibel geloest wurde.
    Das macht den c64 schliesslich ebenso aus.
    Die VIC register sind an zig Stellen das beste Beispiel dafuer :wink:

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Geht natürlich, man muss aber beim Umschalten auch an den Stackpointer denken!

    nein muss man halt nicht mal, das ist ja das coole. beispiel: "lda #bank2 ; sta banking ; (zp/stack ist nun frei) ; jsr routine ; lda # bank0 ; sta banking ; (nun ist es wieder der richtige stack) ; rts".

    SOFTWARE: es waere dann aber nicht das duemmste die aktuelle belegung in ein ZP register zu speichern. so kann dann ein interrupt "ZP-banking laden ; zp/stack umschalten; wert auf stack legen ; irq beackern ; wert von stack nehmen ; banking zuerueck schalten ; rti" - also die aktuelle belegung immer NACH dem umschalten [egal ob zp/oberes ram] dorthin speichern

    Zitat

    Wenn ich den erwähnten 74LS08 durch einen 74LS257 ersetze kann ich die Option des Umschaltens der Bank mit ZP und Stack offen halten. Die oberen 4 Bit des Bankingregisters (74LS574) enthalten dann die Bank der ZP/Stack. Beim RESET muss einer der ersten Befehle dort $00 reinschreiben.

    ok, der 574 hat wohl kein reset...

    Zitat

    ich finde es sogar interessant, wenn am Ende so manches Detail eher effizient als maximal flexibel geloest wurde.

    ich bin da fuer ausgewogen (wenn auch das zp/stack/512byte banking wirklich nur ein bonus und kein must have ist)

  • ok, der 574 hat wohl kein reset...

    Ich hatte vorher schon mal einen 74*273 vorgeschlagen. :whistling:

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich hatte vorher schon mal einen 74*273 vorgeschlagen. :whistling:

    Stimmt, der ginge. Die Pinbelegung ist aber *zensiert*, zumindest für den, der das Platinenlayout machen muss.

    Wenn ich dazu komme schreibe ich die ganzen Details meiner Schaltung hier am Wochenende mal zusammen.