joyceforum.de

Ich vesuch' mal, dem Gerüst von Bernd etwas Fleisch zwischen die Rippen zu geben. Ich fange einmal mit Punkt 6 an (anders herum falle ich mit der Tür ins Haus - nicht so gut).

Zu Punkt 6:

Drucker: wäre schön,

Alle mal ! Ich hatte ja bereits hier (in Verbindung mit dem Wifi-Modem) von meinem eher kruden Versuch berichtet, per Wifi auf meinem Laser-Drucker einen einfachen ASCII-Text aus zu drucken. Allerdings erfolgte das von Qterm aus, was auch überrashnder Weise funktioniert hat. Wenn man also das COM1-Device auf LPT: legt (mit DEVICE), bei aufgestecktem Wifi-Modem, könnte der erste Schritt getan sein. Hier wären aber sicherlich noch einige Experimente notwendig, um mehr Erkenntniss um die Details zu erhalten. Ev. muß auch ein RSX erstellt werden, welches hier das (notwendige) Interfacing vornimmt.

schön, wenn man den Original-Drucker anschließen könnte

Hieran versucht sich im CPC-Wiki Forum bereits jemand, zu finden unter:
https://www.cpcwiki.eu/forum/nc100-nc20 ... ai6grkdbc6
Vielleicht solte man abwarten, zu welchen Ergebnis man dort kommt und sich dann dranhängen. Doppelte Arbeit muß nicht sein, die freie Zeit könnte man in Punkt 3 oder Punkt 1 stecken.

Zu Punkt 5:

Monitor: VGA und/oder Video-Ausgang

Wie die Beschaltung der VGA-Buchse vorgenommen werden kann, kann man bei Grant Searle's Multikomp abkupfern (aber auch an vielen anderen Stellen im Internet finden). Den VIDEO-Out kann kann man bei der PCW-IO Karte hier im Forum nachsehen. Beides ist eher ein Abfallprodukt der ohnehin notwendigen Bilderzeugung. VIDEO-OUT sollte - weil es so einfach - mit angeboten werden.

Zu Punkt 4

Laufwerke:

Da gibt's nicht viel weiteres zu zu sagen, außer: unbedingt. Hier wird jeder seine eigene Schwerpunkte bzw Premissen haben. Aus meiner eigenen Erfahrung mit dem 720k-Format heraus wäre es jeodoch sehr wünschenswert soewtas wie ein HD-Laufwerk (mit 8MB Kapazität) zu haben. /20k sind verdamt schnell voll. Darüber hinaus ergibt sich dann auch die Möglichkeit, solche Goodies wie ZPM3 zu installieren und vernünftig nutzen zu können. John Elliott hat hier für den AMSTRAD PCW/Joyce auf seiner Web-Page einen entsprechenden Patch beschrieben. Zumindest finden sich auf seiner Web-PageDateien, die das vermuten lassen. Zu finden hier:
https://www.seasip.info/Cpm/software/amstrad.html
Man suche nach "AZCCP.PMA"

Zu Punkt 3

Tastatur: USB oder PS/2, Originaltastatur anschließbar

Das mit einer PS/2-Tastatur (USB nur wenn sie auch das PS/2-Protokol beherrscht) ist von HabiSoft's PCW-IO Lösung ja schon bekannt. Zur Original-Tastatur muß man wissen, das sie nur die 3-Draht-Verbindung u. das Hardware-Interface mit einer PS/2-Tastatur gemeinsam hat. Während sich eine PS/2-Tastatur nur beim betätigen und loslassen einer Taste zu Wort meldet, senden das Original einen kontinuierlichen Datenstrom an den Rechner, in dem die komplette Tastatur-Matrix periodisch übermittelt wird. Das CPM sortiert die Daten dann in die im Speicher gehaltene Daten-Matrix ein. Sollen alle drei Tastaturen anschließbar sein, müßte hierfür entsprechend ein eigener Tastatur-Prozesser abgestellt werden, der zum Eine USB- u. PS/2-Tastaturen bedient. Beides ist recht ähnlich im Verhalten und zum Anderen das Original mit seinem Sonderverhalten als Sonder-Device. Jenach dem was man ansteckt (immer nur eine Tastatur zur Zeit oder es muß priorisiert werden), müßte automagisch umgeschaltet werden auf das angesteckte Device. Die anderen sollten für die Dauer abgeschaltet bleiben. Ein gleichzeitiger Betrieb ist sicher nicht sinnvoll und würde ev. alles nur verkomplizieren. Der Anschluß einer USB/PS/2-Maus: fällt in die gleiche Kategorie wie USB- u. PS/2-Tastatur, der Prozessor muß dann nur inteligent genu sein und Maus und/oder Tastur erkennen können. Wie das dann mit den vielen Buchsen gelöst wird, ist zu klären. Einen separate Buchse für jedes Device könnte da von Vorteil sein.

Zu Punkt 2

Kompaktes Gehäuse

Je kleiner die finale PCB ausfällt, umso einfacher dürfte dieser Punkt zu lösen sein. Insbesondere dann, wenn weder ein Colani- oder Porsche-Design gefordert ist. Ich glaube, diesen Punkt kan man entspannt ganz zum Schluß angehen...

Zu Punkt 1

Alle Teile sollten aus aktuell verfügbarer Hardware bestehen;

So, jetzt kommt das, was ganz am Anfang steht: die Tür liegt vor mir am Boden und ich steh' im Haus
Ganz grob dürfte folgendes im ASIC stecken:
- Das Video-Terminal mit seiner Video-RAM Ansteuerung und der Roller-RAM Logik
- Die MMU für Verwaltung des RAM's
- Der Empfangskanal für die Tastatur-Daten
- Die Interrupt-Erzeugung (es gibt eine Software-Uhr und womöglich auch noch andres !)
- Die Refresh-Erzeugung für die DRAM's, wenn das nicht von der CPU abgenommen wird, was ich nicht glaube
- Eine irgendwie geartete Adressdecodierung (es gibt mindestens den Floppy-Contr. u. den Drucker-Prozessor)
- Eine Boot-Logik, die dafür sorgt, das der Kaltstart gelingt (der Boot-Loader kommt vom Drucker-Prozessor)

Genaueres ist im zip-File "amstrad-pcw-technical-info-master.zip" weiter oben zu finden. Das war's erst einmal soweit.

Auch das ich etwas vom linken explizit weglassen muss (Dateioperationen) verwirrt.

Ich häng' mich mal mit obiger Anmerkung von Paul mit einer eigenen Frage hierzu dran. Bei meinen Aktivitäten mit dem HTC unter CPM habe ich das Problem, das ein "Hello World" regelmäßig ein 14K Binary erzeugt, egal was ich versuche. Es macht den Eindruck, als wenn per Default eine ganze Menge Zeugs standardmäßig mit eingebunden wird, obwohl sie eigentlich garnicht benutzt bzw. angefordert werden. Eben solche Sachen wie File-Operationen, Mathe-Funktion etc. Nur für die Ausgabe eines schnöden einzeiligen Textes ist das alles sicherlich nicht erforderlich. Beim Aufruf des C309 vom HTC-Paket startet anscheined ein Batch-Prozessor, der vordefiniert alle erforderlichen Schritte für die Übersetzung nacheinander abarbeitet. Beim zcc dürfte das nicht viel anders sein, wie es scheint. Dieser Batch-Prozess nimmt durchaus zusätzliche Parameter entgegen, aber anscheinend nicht so, das sich damit ein Ausschluß von unerwünschten Dingen im fertigen Binary erreichen läßt. Ich habe Dr. Google einmal hierzu bemüht und bin auf Hinweise gestoßen, das da ev. im C-Standard Papier (hoffe mal, ich formuliere das richtig) Vorgaben definiert sind, wie automatische Compilierung oder explizierte befehlszeilengesteuerte Übersetzung zu behandeln sind. Wenn ich also jeden Schritt einzeln anstoße, kann ich mehr Paramter angeben, die dann wohl auch beachtet werden. Mithin ist eine bessere Beeinflussung des Ergebnis (speicheroptimiert oder laufzeitoptimiert...) möglich.

Ist dazu etwas bekannt ?

Nachdem ich mich einige Zeit mit den Warp-Gondeln für meine Joyce beschäftigt habe und das Thema Erweiterbarkeit sich nicht befriedigend lösen ließ, fiel mir JonB vom CPC-Wiki Forum mit seinen Erweiterungskarten für die Joyce/PCW wieder ein. Nach Studium seiner Wiki-Seite zu den von ihm designten Karten, unter anderen auch eine Backplane, war klar, das es wohl nur so (sinnvoll) gehen würde. Seine Backplane ist jedoch nicht über den Entwurf hinaus gekommen - leider. Bei uns im Forum gibt es auch eine Seite zum Thema SPRINTER, eine Aufsteckkarte auf den CPU-Sockel, um so sowohl das RAM aufzustocken als auch den CPU-Clock zu erhöhen. Damit das alles unter einen Hut paßt, sind bei meiner Backplane 2 Steckplätze als 50-pin Buchsenleiste und 4 weiter mit je 40 Pins (ausschließlich CPU-Signale) vorgesehen. Das reicht also für den SPRINTER-Clone (ich nenne das mal so, es wird aber was eigenes werden, da ich zum Einen keine Unterlagen zu diesem Board habe und zum Anderen eigene Ideen habe) und 4 weteren Steckkarten. Zur Zeit sollen das eine CF-Adapter Karte, eine I2c-RTC mit I2c-Bus und ein CPS8256-Clone sein. Der letzte Steckplatz bleibt ersteinmal offen. Soweit die Theorie...

Derzeit exitiert die Halbschale zusammen mit der Anschlußplatte für einige DB-Buchsen/Stecker und dem Prototypen meiner Backplane. Leider dauert es mit der CF-Adapter Karte, welche ich bei JonB angefragt habe etwas länger. Mit ihr wollte ich eigentlich anfangen, um endlich etwas größere Laufwerke nutzen zu können, aber gut Ding braucht Weile...

Deshalb erst vorerst ein CAD-Bild, wie die Mechanik aussehen soll:

Der zweite Teil der Doku zur Joyce_DE, die step- u. stl-Daten:

Es hat etwas gedauert, aber jetzt ist die Doku für die JoyceDE fertig. Dieser Datensatz behandelt nur die mechanischen Änderungen für die deutsche Mainboard-Version, also die Rückwand und den Gondelhalter sowie die Bohrungen in der Deckelschale. Für den Rest wird auch der Datensatz der englischen Version benötigt.

Hier die Files:


Der Rest im nächsten Beitrag...

Toll, das Du mit machst. Ich hoffe, Du kannst aufschließen, bevor Bernd weiter macht.

Wundert mich, dass es einen PCW Core fuer den MISTer gibt, aber keinen fuer den MIST.

Mich auch, zumal es den PCW-Core schon seit 3 Jahren auf Github gibt.

Sieht gut aus

ok, ich leg' meinen Vorschlag denn mal zu den Akten.

Über die Zeit habe ich einige interesante Doku zur Joyce im Internet aufgesammelt. Hier mal die unsortierte Liste:


Die Files dokumentieren recht gut die Joyce. Insbesondere das zip-Archiv enthält interessante Info's zum Innenleben des ASIC's. Ich stell' das einmal so zur Diskussion. Die URL's zu den Fundorten stehen zum Teil in der Kopfzeile. Sofern pdf's direkt angeboten wurden, fehlt die URL. Die Inhalte der Dateien beruhen nicht auf meinem Dazutun, sondern sind Werke der jeweiligen Autoren. Ich stell' die Text hier nur in nutzbarer Form zur Verfügung, denn anders könnte man sonst damit nicht oder nur recht umständlich arbeiten.

Die Vorstellung 'mal eben' den Inhalt des ASIC's durch TTL-Logik ersetzen zu wollen ist ein mutiger Gedanke. Für's Protokoll: Das ASIC beinhaltet 3000 Logokzellen, wobei die Zellen aus allen möglich Logik-Baussteinen bestehen. Siehe nachfolgendes Datenblatt des eingesetzten ASIC's auf den Seiten 6...7.


Nach meiner Erfahrung wird der Inhalt des ASIC's von den AMSTRAD/Schneider Entwicklern weitgehend ausgenutzt worden sein, weglaßbare Schaltungsteile sind da sicherlich nicht eingebaut worden, das wäre Geldverschwendung gewesen - also eher keine Chance. Es wird nicht zu vermeiden sein, ALLES nachzubauen. Dein Haufen TTL dürfte da schnell in ein TTL-Grab ausufern. Vom zu erwartenden Stromverbrauch einmal abgesehen. Nach meinem dafürhalten wäre folgenden Zusammenstellung der Erfolgversprechenste Weg:
Für die Peripherie bietet sich das PS/2-Protokoll wegen seine einfachheit an. USB sattelt nur noch mehr Technik drauf - wozu ? PS/2 Keybrd's und Mäuse gibt's immer noch genug. den Floppy-Controller samt Dataseparator gibt's nur noch als NOS. Sollte er noch mit ins FPGA pasen, wäre das begrüßenswert. Die CPU lasse ich mal absichtlich außerhalb des FPGA's, da sie mit 2500 LE's faßt 1/3 der 6500 LE's des FPGA's verschlingt. Besagtes FPGA-Board ist hier zu bewundern:

https://www.ebay.de/itm/115620910433?ha ... R_SB77vbYQ

Ein passendes FPGA-Board wäre eines mit 15k-LE's, aber da sehe ich keine zuverlässige Liefersituation, heute gekauft u. morgen ausverkauf ist nicht hilfreich. Ali-Express blendet mittlerweile alle Händler aus, die nicht bereit sind, sich eine europäische Steuernummer zu besorgen (was die meisten sind). Da bleibt fast nichts mehr zum Bestellen übrig. Schon garnicht was hier sinvoll wäre.

Zum HDL-Code des Cores: Es gibt auf Github ein Repository mit einem AMSTRAD-PCW Core, ausgekoppelt aus dem MISTer-Projekt vermute ich mal, den man verwenden kann. Einziges Problem: er ist in System-Verilog verfaßt und davon habe ich keine Ahnung. Ich habe bisher nur VHDL genutzt. Da wäre zuvor etwas Forschungsarbeit notwendig, nicht nur um heraus zu bekommen, ab welcher Quartus-Version das unterstützt wird. Ich arbeite immer noch mit der 13.0.1-Version und die kann wohl nur max. VHDL u. Verilog (Quartus-Installation ca. 13GB).

Core auf Github ist hier zu bewundern:

[/url]https://github.com/MiSTer-devel/Amstrad-PCW_MiSTer[/url]


Was VGA und/oder BAS-Video angeht, habe ich im Core noch nicht nach gesucht. Aber ich glaube, der MISTer hat eine VGA-Ausgang.

Hi Wener, Bernd, Paul und Sven, kann einer von euch einen Link präsentieren, wo man sich den ZEDDY mal ansehen kann ! Ich dreh' mich bei der Suche danach im Kreis und lande häufg bei "Teddy" - Dr. Google ist sowas von einfallslos....

Ich würde gern verstehen, was ihr mit "damit ist man weg von den ‚alten‘ (schon jetzt nicht mehr verfügbaren) Komponenten." meint. Denn diese Problematik ist beim ZEDDY ja, so scheint es, auf besondere Weise gelöst worden. Das hätte ich mir gern angesehen.

Könnt ihr vielleicht in wenigen Sätzen einmal zusammenfassen, welche Optionen ihr für die Realisierung der einzelnen IC's in der Joyce andiskutiert habt (ich würde nur ungern mit Vorschlägen aufwarten, die bereits behandelt wurden) ? Das Asic in der Joyce ist ja z.B. ein zentraler Baustein. Die Funktionalitäten von Floppy- und Drucker-Controller müssen realisiert werden, wenn schon nicht die original-IC's zum Einsatz kommen sollen. Man könnte soetwas emulieren - moderne schnelle Mikrocontroller gibt es ja mittlerweile genug, auch wurde soetwas schon oft gemacht...