Apple2IORPI

  • Weil ich noch auf die Shenzen Schneckenpost warte, für benötigte Bauteile, hab ich mich mal genauer mit dem Schaltplan für Apple2iorpi beschäftigt.
    Der ist ja wirklich von hinten ins Knie....
    Merkwürdiger Handshake und ein Wunder, dass es überhaupt funktioniert, mit diesem komischen doppelten Hanshake.
    Keine Synchronisation der R/W mit PHI1 (ist gar nicht benutzt).
    Die Anbindung des (EEP)ROMS ($C800...$C8FF) verursacht mit Sicherheit Probleme mit Karten, die auch den 2k Speicherbereich nutze, wie z.B. die 80Z Karte.
    Ich kann das Flipflop nicht finden, dass dafür sorgt, dass die Karte den Speicherplatz nutzt und bei Zugriff auf $CFFF wieder frei gibt.
    Im MC Apple-Sonderheft, https://ia801700.us.archive.or…as%20Apple-Sonderheft.pdf
    S87ff, Universalschnittstelle.... wird genau erklärt, wie die ROM-Anbindung richtig gemacht wird. Das ist zwar eine 6522 Karte, aber es geht ja um die ROM Anbindung. Desweiteren ist die Verknüpfung von R/W und PHI1 erklärt, aber in den Nachträgen, S. 95 korrigiert.
    Wenn ich in der Schaltung statt des 6522 eine CH376 Board in die Schaltung einpasse, hab ich etwas ähnliches, wie die BOOTI card.
    Bisher habe ich nur mal zum Test das CH376 Bord, ohne ROM, an den Bus angeschlossen, es scheint zu funktionieren, eine Abfrage ob das device present ist, funktioniert, genau wie die Afrage der Firmware Version.

  • Ok, Wozu ist dann das 8kB EEPROM?
    Nur für die 256 Byte Bootrom?
    Warum liegen dann A0 bis A10 vom ROM am Apple Adressbus , also werden 2k vom ROM adressiert ?
    A11 und A12 gehen an einen LVC374 um zwischen vier 2k Bänken umschalten zu können.
    Ich ärgere mich jetzt schon, dass ich die Platinen geordert habe, statt selbst etwas zu entwerfen.
    Ich muss mir mal Experimentierplatinen (Lochraster Slotcard) besorgen und was eigenes entwickeln.
    Leider hab ich nicht wirklich viel Ahnung von programmierbarer Logik, bei PAL, GAL gehts noch, aber FPGA usw. nicht wirklich, daher wird es wohl ein 74er Verhau.

  • Terence hat mir geschrieben, dass er ein Expansion ROM ganze bewusst weggelassen hat, weil der die Komplexität der Umschaltung vermeiden wollte - insbesondere bei der 80 Zeichen Shell. Oder anders ausgedrückt: Zur cooleren Hardware brauchst Du dann halt auch coolere Firmware. Ich kann/will nicht beurteilen, wie gut Du darin bist, Dir die dann zu schreiben. Für mich persönlich liegt der Wert eines Projekts wie Apple2-IO-RPi nicht in der Hardware, sondern in der Firmware und Software. Insofern also kein Wunder, dass ich mit neuer Hardware um die Ecke komme, die aber die original Hardware über weite Strecken emuliert, damit ich die Firmware und Software nicht total umbauen muss - was z.B. spätestens dann doof wird, wenn Terence seine Firmware und Software um neue Funktionen erweitert, und ich diese Änderungen alle in meine eigene Variante einbauen müsste. Aber das handhabt natürlich jeder alles so, wie es für ihn am besten ist.

  • Gute Frage, ja Firmware traue ich mir zu, nur die Prodos Geschichte ist nicht so meins. Ich denke mit der richtigen Literatur, einige Artikel in PEEKER, MC und anderen Computerzeitschriften sind meine bevorzugte Quelle, bzw. waren sie schon in den 70ern 80ern wirds schon klappen. Da sind auch die ganzen PRODOS APIs erklärt.

    aber, mein Steckepferd ist dann doch die Hardware, die Software eher ein "muss".

  • aber, mein Steckepferd ist dann doch die Hardware, die Software eher ein "muss".


    Dann würde ich Dir stark dazu raten, Dir etwas zu bauen, bei dem Du vorhandene Firmware / Software übernehmen kannst. Ich will Dir nicht zu nahe treten, aber der Aufwand, der darin steckt, wir von Hardware-"Bastlern" gerne sehr falsch eingeschätzt.

    Just my two cents

  • Hm...
    Zuerst mal, ich mache das ganze nur, weil es mir Spass macht.

    Individuelle Firmware pro Slot, warum?
    Das macht doch nur Sinn, wenn die Firmware schlecht geschrieben ist und den Slot nicht selbstständig erkennt.
    Ich mache eine Abfrage, in welchem Slot sich die Karte befindet, was ausreicht, desweiteren benutze ich relozierbaren Code.

    Code zum herausfinden der Slotnr.:
    JSR $FF58 oder irgendeine andere ROM Adresse mit RTS Anweisung

    TSX Stackpointer nach X
    LDA $100,X $Cn nach Akku, wobei n die Slotnr. ist.
    Nach dem Apple][ Referenz Manual, soll die kodierte ($Cn) Slotnummer im Scratchpad RAM $7F8 gespeichert werden und ist dann für die indizierte Adressierung vom scratchpad Bereich zu verwenden.

    Vielleicht ist das etwas oldschool, aber erstens bin ich alt und zweitens halte ich mich damit an die Apple Vorgaben.
    Bisher nutze ich für die Entwicklung ein 2k SRAM statt ROM.
    Die 256 Byte Firmware (Bootrom) werden im RAM in den oberen 256 byte gespeichert.
    Dann sind noch 1 3/4 kB benutzbares RAM im expansions Bereich, was recht praktisch ist, als Scratchpad RAM, oder einfach als Buffer.

  • Hm...
    Zuerst mal, ich mache das ganze nur, weil es mir Spass macht.

    Du klingst so, als hätte Dich hier jemand angegriffen. Du hast nicht verstanden, wofür das ganze ROM ist und ich habe es Dir erklärt. Nicht mehr und nicht weniger.

    Individuelle Firmware pro Slot, warum?

    Vermutlich ist das eine rhetorische Frage, aber womöglich liest ja jemand mit, den es tatsächlich interessiert:

    • Einsparen von Platz und Zyklen für die von Dir beschriebene Erkennung
    • Einsparen von Zyklen durch die absolute statt absolut-indizierte Adressierung beim I/O Zugriff
    • Auch beim 6502 Möglichkeit der Nutzung des BIT Befehls beim I/O Zugriff (spart oft Platz und Zyklen)
    • Freie Nutzung des X Registers für andere Zwecke (spart wieder Platz und Zyklen)
    • Kein Workaround für den Phantom-Read bei STA,X z.B. beim 6551 notwendig (spart dann Platz und Zyklen)

    [...] und zweitens halte ich mich damit an die Apple Vorgaben.

    ...aus einer Zeit, als man ROM in Gold aufgewogen hat. Nur wenige Jahre später hat es auch Apple nicht mehr so gemacht. Z.B. bei der Slinky RAM Firmware oder bei der 3.5 Floppy "Liron" Controller Firmware.

  • Ok, das sind gute Argumente.
    Das werde ich übernehmen, da meine Experimentierkarte 2kRam hat, muss ich die Firmwate erstmal ins Ram laden,bleibt bei reset erhalten.
    Da kann ich dann jeweils die für den Slot passende Firmware laden.
    und nee, ich fühle mich wirklich nicht angegriffen´sorry´, wenn das so rüber kam.

  • Hallo entschuldige mein Deutsch. Ich komme aus Holland. Ich habe gerade 20 74LVC374 bestellt von Mouser. Wenn jemand interessiert is gerne anschreiben. Ich brauche selber nur 10 stuck. Ich habe auch noch 4 komplette Apple2-IO-RPi wenn alles funktioniert :)

  • Hallo osenbruggen,


    von den 374 Chips würde ich dir 5 Stück abnehmen und auch einen funktionierenden Apple2-IO-RPI.

    Das ist warscheinlich nur die Platine ohne Raspi, oder.

    Einen Raspi hab ich dafür noch hier.


    Alles weiter per PN?


    Viele Grüße,


    Olaf

  • Hallo,


    ich melde mal auch Interesse an. An komplettem Modul, Platine plus Spezial-ICs oder nur Platine. Je nach Verfügbarkeit. Möchte mit meinem IIe doch mal etwas anfangen.


    Gruß, Rene

  • Entschuldige für die späte Antwort. Ich vermisse noch 28C64B für die komplette Platinen. Leider weiß Ich noch immer nicht wann Ich die bekommen werde. Die 347 Chips habe Ich bekommen. Hab schon Fragen für 7 stuck so habe noch 3 Stuck.

  • Die Karte funktioniert auch problemlos mit einem "normalen" (also nicht Zero) RPi. Nicht unbedingt vorhersehbar war, dass sich die Karte und die RPi USB Buchsen nicht in die Quere kommen :)



    Auch bleiben erfreulicherweise beide Nachbarslots voll einsatzfähig :)


    Nur mit dem Deckel auf dem Apple II wird das nicht mehr so ganz ;) Aber ohne Deckel und mit nach oben herausstehendem Ethernet-Kabel sieht ein Apple II sowieso viel cooler aus 8o


    Ach ja, die neuest Board Revision hat ja einen Jumper, um den RPi wahlweise extern (per Micro-USB) mit Strom zu versorgen, was sich natürlich für dieses Setup anbietet. Dann gerne auch mit einem RPi4 - für Performance jenseits von RPi Zero's...