Beiträge von ol.sc

    Neues von David Kuder:

    prototype of the GS specific version of my VGA card. Has 12-bit RGB to match the GS, a larger CPLD to handle the slot selection logic and qualifying PHI0 with M2SEL/M2B0. The VGA connector is on a separate breakout so it can be mounted in a IIgs or IIe, or replaced with other I/O modules for WiFi, Serial ports, etc.

    Hallo Joerg,


    schöner Bericht und tolle Aktion :)


    Ich hatte in meinem Europlus irgendwann in Slot 7 eine RGB-Karte vom Grabbeltisch. Da konnte ich direkt einen SCART Stecker anschließen. Dann noch ein Verlängerungskabel für den Joystick und die Gaming Sessions am Bigscreen waren gebongt!


    Gruß, Oliver

    Without going into details I'm pretty sure that your ideas fit to the hardware in question.


    There's even a "EPROM routine" to memcpy() a whole block from "low64" to "up64" (and vice versa). So maybe your "shadow" routines aren't necessary at all.


    But apart from that, your "shadow" routines are what others name "trampoline". They are a usual pattern on the hardware in question.


    So, I believe this could work - however I'm personally not interested in working on it ;)

    Wenn es so gut funktioniert wie es aussieht...

    Eine Kleinigkeit noch von meiner Seite: Der Taster is ja ein "Not RUN" Taster. Ich würde ihn mit 'RESET' beschriften.

    1. Danke für das positive Feedback :)

    2. Die Idee mit den zwei IDC16-Headern und einer Sollbruchstelle dazwischen ist cool!

    3. Für Entwickler wäre evtl. noch ein Button interessant, der den Pico RUN Pin auf GND zieht. Damit könnte man dann den Pico Flashen ohne dazu immer das USB Kabel abziehen zu müssen.

    Wenn man sich https://m.youtube.com/watch?v=ReTXGczq8Vk anschaut, dann sieht man auch direkt die Folge der Run Pin Entscheidungsänderung: Nach einem A2 Reset bleibt der 80 Zeichen Modus hängen.


    Bei meinem/unserem Design war glücklicherweise noch ein Pico GPIO Pin frei, so dass ich den A2 Reset dort anschliessen konnte. Mit einem Pico Interrupt Handler auf steigender Flanke des Pins kann ich dann genau das reseten, was ich will.


    Hier sind aber leider schon alle Pico GPIO Pins belegt. Darum wird ein Firmware Hack notwendig werden, der analog zum Hack im IIgs den Reset am Speicherzugriffsmuster der CPU erkennt.

    David's Board hält sich augenscheinlich zumindest an die erste Vorgabe: https://hackster-imgix-net.cdn…7330/image_DrvxPIzzPj.png


    Übrigrens: Die Isolation am Run Pin des Pico W auf diesem Foto kommt mir konzeptionell bekannt vor. Auch bei meinem/unserem ersten Design wurde der Pico mit dem A2 resetet. Beim Pico macht das alles schön einfach, aber beim Pico W will man nicht bei jedem A2 Reset wieder die komplette WLAN Anmeldung durchlaufen.

    Auf David's Website ist ein Pico W zu sehen. Auch wenn die heutige Firmware noch keinen Nutzen aus dem WiFi Modul zieht, so ist doch abzusehen, dass sich das ändert.


    Für einen Pico W sollte das Board aber anders sein: Im Bereich der Antenne keinerlei Traces sein. Aus dem Datasheet:


    For best wireless performance, the antenna should be in free space. For instance, putting metal under or close by the antenna can reduce its performance both in terms of gain and bandwidth. Adding grounded metal to the sides of the antenna can improve the antenna’s bandwidth.


    Und am besten auch kein PCB: https://datasheets.raspberrypi…re-design-with-rp2040.pdf Chapter 3

    Ich kann zu den meisten Änderungen leider nichts sagen :(


    Aber die Sache mit dem IDC-Header ist toll, weil man einen (zumindest typischen) VGA Stecker nicht durch die Öffnungen eines //e oder IIgs bekommt :)


    Bis vor einigen Jahren hat man ja so etwas leicht bekommen: http://www.suntekpc.com/htm-2/…add-hd15f-oem-190314a.htm Da war die VGA-Kupplung hübsch vergossen - ideal für den Einsatz hier. Aber inzwischen gibt es solche Dinger nicht mehr...

    Das wäre so, wenn es nur darum ginge, mit den Zugriffen auf die Softswitches "nur" Dinge zu tun. Du schreibst aber "Kann ich dem Rechner vogaukeln, dass er DHGR kann" und dazu gehört, dass der Rechner der Software auf jede Menge Auskunft über den aktuellen Stand der Softswitches gibt. Und da reicht eine passive Überwachung nicht aus. Das gleiche übrigens auch für das Video RAM: Software schreibt ja nun nicht unbedingt nur ins Video RAM, sondern liest auch daraus, z.B. beim Scrollen.

    > Also vermutlich auf 9600 für's bootstrappen. Das brauch ich aber eigentlich nicht, hab ja schon ne Floppy per Handy erzeugt. Scheint ja eher wurst zu sein, weil die Werte per Software gesetzt werden.


    Genau. Die sind nur für die SSC Firmware (IN#x/PR#x). Das eigentliche ATDPro interessiert sich für die DIP-Switches nicht.


    > Nutzt ADTpro nur RXD & TXD oder auch die Hardware-Flowcontrol RTS/CTS usw?


    ADTPro nutzt keinerlei H/W Handshake Leitungen.


    > Ich werde wohl mal messen. Aber das wäre einfacher, wenn ich wüsste, welche Leitungen ADTpro denn verwendet.


    Du kannst Dein Serial-Setup statt mit ADTPro auch mit einem beliebigen Terminal Programm oder so ausprobieren/testen. Da ADTPro kein H/W Handshake nutzt, funktioniert jenes dann auch. Da einzig besondere an ADTPro ist, dass es den 6551 fest auf 115200 statt auf die eher üblichen 9600 oder 19200 setzt. Das muss halt der Rest Deines Serial-Setup auch hergeben.


    Viel Glück!

    Deine Antwort zeigt, dass Du es - wie von mir befürchtet - noch nicht verstanden hast: Mehr oder weniger jede DOS 3.3 Diskette wurde mit INIT HELLO formatiert (oder auf die eine oder andere Weise von einer so formatierten Diskette kopiert). Das heißt, dass Du einfach nur irgendein Applesoft Programm auf die Diskette kopierst (und ggfs. in HELLO umbenennst). Die Wahrscheinlichkeit, dass Du das noch "aktivieren" mußt, geht gegen Null.

    habe sogar mühevoll eine diskette mit init hello formatiert

    Nur um Missverständnisse zu vermeiden: Genau das ist unnötig bzw. bringt keinen Vorteil.

    man mit Copy II plus auch das Init Programm auf bestehenden DOS 3.3 Disketten ändern kann

    Das ist in der Tat eine tolle Lösung - allerdings für ein Problem, das der Themenstarter nicht hat. Ich glaube, dass er dadurch eher verwirrt wird.


    Am Rande: Ich hatte oben explizit 'Applesoft Programm' geschrieben. Das besondere an dem Copy II Plus Feature ist, dass man damit auch Binärprogramme zum Autostart Programm machen kann, was mit der klassischen INIT Methode nicht geht.

    Ich kenne das primär für DOS3.3. Bei DOS3.3 is der Defakto-Standard, dass nach dem Booten ein Applesoft Programm namens HELLO ausgeführt wird. Entsprechend haben solche Disketten schlicht ein HELLO Programm drauf, das genau das von Dir beschriebene tut. Man kann das einfach von einer Diskette auf eine andere kopieren. Da ist nichts magisches dabei. Du musst nur eine Diskette finden, die so ein HELLO Programm drauf hat - da gab es unzählige von.


    Technisch arbeiten diese Programme übrigens alle so, dass sie das CATALOG Kommando an DOS3.3 absetzen und danach mit der geeigneten Menge von PEEK und POKE aus der von DOS3.3 erzeugten Ausgabe ein Menü basteln.

    1. Der Contiki FTP-Client hat eigentlich noch nie so richtig funktioniert. Insbesondere unterstützt er kein Passive FTP. Darum habe ich ihn schon sehr früh aus meinen Contiki Builds entfernt.


    2. Für 8-bit Apple II weiß ich von keinem ansatzweise brauchbaren FTP Client.


    3. Für GS/OS mit Marinetti gibt es SAFE2.


    4. Womöglich ist für das fragliche Szenario HTTP eine Alternative (natürlich nur für Downloads). Da gibt es drei mir bekannte Clients:

    - Contiki wget (Uthernet I + II)

    - A2osX httpget (Uthernet I + II)

    - IP65 wget65 (Uthernet II)

    Keines dieser Programme läuft auf einem ][+.

    1. ProDOS hat eigentlich den Anspruch, bei seinem BASIC Interface weitestgehend kompatibel zu DOS 3.3 zu sein. Wenn Du also bei "gängigen" Problemstellungen das Gefühl hast, zwischen DOS 3.3 und ProDOIS unterscheiden zu müssen, könnte das ein Hinweis auf ein Problem "bei Dir" sein.


    2. PEEK(48.896) ist bei ProDOS gleich 76, bei DOS 3.3 hat es einen anderen Wert. So steht es z.B. in 'Beneath Apple ProDOS' Seite 6-63.

    Da kann man mal wieder sehen... Statt einen Aufwand zu treiben, um ein Apple II-fremdes Disk Interface am Apple II ans Lauf zu bekommen, und dann auf ein gepatchtes CP/M angewiesen zu sein, dass diese Interface unterstützt, würde ich viel eher auf die Idee kommen, das CP/M so zu patchen, dass es das Apple II-native SmartPort Interface unterstützt. Mit Zweiterem würde man dann auch der Community einen Dienst erweisen. Aber es wäre ja denkbar langweilig, wenn wir alle die gleiche Meinung hätten ;)

    > Ansonsten hoffe ich, daß es doch noch Lösungen gibt, mit denen man Disketten oder Images nutzen kann. Diskemulatoren gibt es ja wohl (Floppy Emu) aber ob die CP/M kompatibel sind?


    Ein "vernünftiger" Floppy Emulator (wie z.B. https://www.bigmessowires.com/floppy-emu/) ist CP/M kompatibel.


    > Am liebsten wär mir ja eine DIY Steckkarte, die dem Apple ein "modernes" 26poliges Floppyinterface spendiert. Aber wahrscheinlich war die Apple-Floppylösung dafür zu speziell.


    Genau, das geht so nicht.

    Ich will nicht sagen, dass das Dein Problem löst, aber meines Wissens nach vereinigt CP/AM 5.1 diese beiden Eigenschaften:

    - Läuft auf MS Softcard kompatiblen Z80 Karten

    - Bootet von / läuft mit SmartPort kompatiblen Massenspeichern.


    Warum löst das vermutlich Dein Problem nicht? Weil CP/AM 5.1 wohl so wenig Speicher für die Applikation übrig läßt (-> TPA aka Transient Program Area), dass relevante CP/M Programme nicht laufen.


    Alles was oben steht, weiß ich nur von anderen. ich selbst habe keinerlei eigene Erfahrung!

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