Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Konkurrierende Zugriffe auf IRM durch CPU und IRM-Logik » Themenansicht

Autor

Thread - Seiten: -1-

000
05.04.2024, 22:30 Uhr
HeikoS

Hier das Thema, welches im Thread https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21866 ab <008-014> begonnen wurde, aber dort nicht hingehört.

Zitat:

jute-tom schrieb
Es gibt allerdings andere Z8-Prozessoren, wo es die Register von 0x80-0xEF auch gibt, wobei der Bereich von 0xE0-0xEF nur durch Arbeitsregister zugreifbar sind.

Ein pop #80 wurde übrigends beim 2k Ju+Te für das Auslesen des Videorams zur Erzeugung des Videosignals genutzt.

Zitat:

HeikoS schrieb
Das ist ja interessant. Der BCS3 nutzt ja NOP's, um die Adressen der CPU hochzuzählen und den BWS auszulesen. Der Zeichengenerator sieht die BWS-Daten und die CPU NOP's bis zum Zeilenende.

Wie ist das beim JuTe 2K gelöst? Wie spielt pop #80 dabei eine Rolle? Habe ich mir noch garnicht genau angesehen. Und wie ist es beim JuTe 6K gelöst? Hat schon mal jemand den ROM des Videoteils disassembliert?

Viele Grüße, Heiko

Zitat:

jute-tom schrieb
Ziel beim 2k Ju+Te ist, den Videoram kontinuierlich anzusprechen, die Adresse hochzuzählen und das Timing einzuhalten. Dafür wurden pro Zeile 8x (nop, pop #80) genommen:
https://github.com/tmssngr/z8asm/blob/master/src/main/examples/2k-1988.asm#L361

Den Video-ROM findest du u.a. hier disassembliert:
https://github.com/tmssngr/z8asm/blob/master/src/main/examples/video.asm

Es gibt aber auch andere Quellen davon.

Zitat:

HeikoS schrieb
Danke für die Infos ! Den JuTe 2/4K hat Volker auch sehr gut disassembliert und kommentiert. Den Video-ROM vom 6K sehe ich das erste mal hier disassembliert. Super !

Das schaue ich mir genau an ... ich habe ja immer noch die Hoffnung einen Weg zu finden, die Bild-Störungen durch den Zugriff der Host-CPU geschickter zu unterdrücken, als in der Austastlücke zu arbeiten. Da gibt es ja unterschiedliche Wege.

Die mit Abstand beste Lösung ist aus meiner Sicht beim Original-ZX-Spectrum zu finden, der den CPU-Takt für einen winzigen Moment anhält, bis die BWS-Logik die Daten in die Schieberegister geladen hat. Das geht durch geschicktes Ausnutzen des Z80-Timings. Die Adress-Information wird früh genug ausgegeben um zu detektieren, dass auf den BWS-Speicher zugeriffen werden soll. Dann kommt die Takt-Anhalte-Logik zum einsatz. Genial - das ist sehr gut im Buch von Chris Smith beschrieben: http://www.zxdesign.info/book/. Das Buch habe ich schon rauf und runter gelesen. Es ist hier ganz sicher bekannt - zumindest in der Spectrum-Fraktion.

Einige mir bekannte Spectrum-Clones verwenden WAIT. Wie ist es eigentlich im KC 85/4 gelöst ? Der /3 hatte ja auch dieses leidige Problem.

Für den JuTe 6K eine Lösung zu finden, wäre eine schöne Knobel-Aufgabe. Hat jemand Ideen dazu? Ich muss erstmal den kleinen aber feinen Video-ROM-Code komplett verstehen.

Viele Grüße,
Heiko

Zitat:

Bert schrieb

Zitat:

HeikoS schrieb
Wie ist es eigentlich im KC 85/4 gelöst ? Der /3 hatte ja auch dieses leidige Problem.

Ja, auf dem /3 hat die CPU Vorrang, was zu den sichtbaren Störungen führt.
Beim KC85/4 gibt es drei Zeitslots pro 8 Pixel:
1x wird die Farbe gelesen (duf),
1x wird die Pixelinformation gelesen (dup) und
1x darf die CPU auf den IRM zugreifen (duz).
Damit kommen sich die Zugriffe nicht mehr in die Quere.

Grüße,
Bert

Zitat:

HeikoS schrieb
Danke Bert ! ... Habe den Schaltplan vom KC85/4 von robbi angeschaut.

Die Signale duf, dup, duz werden aus dem ersten Zähler (D401) abgeleitet und teilen die Zeit für 8 Pixel in die 3 Bereiche. Die CPU greift aber asynchron (t) zu diesem Raster auf den BWS zu. Wie wird denn der CPU gesagt dass sie warten muss, wenn die BWS-Steuerung die Pixel/Farben benötigt zum Zeitpunkt (t) ?

Grüße,
Heiko

Zitat:

Bert schrieb

Zitat:

HeikoS schrieb
Die CPU greift aber asynchron (t) zu diesem Raster auf den BWS zu. Wie wird denn der CPU gesagt dass sie warten muss, wenn die BWS-Steuerung die Pixel/Farben benötigt zum Zeitpunkt (t) ?

Jain.

Im CAOS-Handbuch findet sich dieser Satz:

Zitat:

Die Zugriffszeit auf den gesamten IRM-Speicherbereich von 8000H bis BFFFH kann
sich auf 2,4?s erhöhen, da der Speicherzugriff mit dem Grafiksystem synchronisiert
werden muss. Dies verzögert die Programmabarbeitung in diesem Bereich.

Das hatte ich mir mit dem Oszi vor Jahren mal angeschaut. Da gibt es ein Signal, was die CPU kurz warten lässt, falls sie gerade nicht dran ist. Allerdings passierte das bei meinen Untersuchungen genau einmal und danach waren alle weiteren CPU-Zugriffe auf den IRM 'automatisch' synchron.

Die Details müsste ich auch erst wieder aus dem Schaltplan raussuchen.

Viele Grüße,
Bert

Dieser Beitrag wurde am 06.04.2024 um 09:14 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
06.04.2024, 11:29 Uhr
P.S.

Das Problem der parallelen Zugriffe auf den BWS (Bildwiederholspeicher) von CPU und Bildschirmablaufsteuerung (egal ob das eine Diskretlösung mit TTL-Zähler ist, oder ein GDC) hatte mich bereits beim ersten Versuch eines ZX-Spectrum-Nachbau sehr beschäftigt. Ihr könnt Euch sicher daran erinnern -> https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=3786 (22)/(23) - Mir war damals nicht klar geworden, wie man sowas lösen kann ...
Jörg hatte dann die beiden Positionen bekommen und dem habe ich auch noch einige zusätzliche Infos per eMail mitgeteilt.

Als dann ab 1985 die KCs aus Mühlhausen zur Verfügung standen und deren IRM-Zugriffe häßlich Störungen im Bildaufbau verursachten, hatte ich halt angenommen, daß das so sein muß und nicht anders geht. Durch das Timing des Bildaufbaus für Fernseher/Monitor war man an dessen Vorrangigkeit beim Speicherzugriff gebunden.
In Fachzeitschriften gab's zahlreiche Lösungsvorschläge - u.a. CPU-Zugriffe nur während den Austastzeiten (Zeile & Bild), was aber wiederum Einschränkungen bei der CPU-Arbeit bedeutet.

Erst viel später beim Bau meines Experimental-Computers -> http://www.ps-blnkd.de/EXPR/Expr.htm und intensiver Beschäftigung mit den Timing-Problemen bei der Entwicklung der GDC-StE -> http://www.ps-blnkd.de/EXPR/Expr.htm#GDC konnte Dank des sog. "Page-Modus" moderner dRAMs mit entsprechender RAS/CAS-Taktung innerhalb sehr kurzer Zeit (wenige 100ns) jeweils ein BWS- und ein CPU-Zugriff nacheinander realisiert werden. Störungen beim Bildaufbau sind somit ausgeschlossen. Details siehe Entwicklungsbeschreibung -> http://www.ps-blnkd.de/EXPR/EXPR_GDC.pdf und http://www.ps-blnkd.de/EXPR/Inbetriebnahme_GDC.pdf.
Leider ist bisher niemand bereit gewesen den "ExpComp" weiter zu bauen. Wie bekannt befindet sich das Gerät mit allem Zubehör im Elektromuseum Erfurt.

Beim KC85/4 sollen solche Bildstörungen durch IRM-Zugriffe nicht mehr sein - kann ich nicht beurteilen, hatte leider nie so'n Gerät ...

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
06.04.2024, 13:07 Uhr
HeikoS

Hallo in die Runde, hallo Peter,

wenn man erst anfängt, taucht man schnell immer tiefer in die alten Zeiten ein ... Ich habe mal meine alten Unterlagen zum ZX-Spetrum-Modul meines CP/M-Rechners von 1987 gesichtet - tatsächlich alles wiedergefunden.

Damals hatte ich die Pixel-Daten per /BUSRQ, /BUSAK aus dem 64K DRAM gelesen. Für die Farbattribute wurde ein zusätzlicher 1K SRAM verwendet. Da konnte sich natürlich auch nichts in die Quere kommen ... das hatte ich schon vergessen. Ist ein Konzept, was aus dem GC204 stammen könnte - zumindest habe ich eine extrem vergilbte Kopie noch gefunden davon.

Der KC85/4 hat das Problem auch gelöst !!! Beim KC 85/4 vermute ich fast, dass auch der Takt angehalten wird, wie beim Original-Spectrum, aber ich habe den Schaltplan noch nicht komplett studiert ... Bert hilft bestimmt mit :-)

Viele Grüße,
Heiko

Dieser Beitrag wurde am 06.04.2024 um 13:09 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
06.04.2024, 13:40 Uhr
jute-tom

Ich plane, im Rahmen meines Tang-Nano-9k-Projektes ja auch den 6k-Ju+Te nachzubauen. Ich gehe davon aus, dasss es dabei sinnvoller ist, den Videoprozessors statt mit einem zweiten UB88x0 durch klassische FPGA-Hardware nachzubauen. Das ließe dann Raum z.B. für eine VGA-Variante (oder sogar DVI-Variante) und könnte evtl. so organisiert sein, dass der Zugriff störungsfrei erzeugt wird.

Insofern bin ich auch sehr interessiert an Möglichkeiten, den Video-RAM-Zugriff des Prozessors störungsfrei für das Videosignal zu ermöglichen.
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 06.04.2024 um 13:41 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
06.04.2024, 20:48 Uhr
Bert

Zitat:

HeikoS schrieb
Beim KC 85/4 vermute ich fast, dass auch der Takt angehalten wird, wie beim Original-Spectrum,...

Fast richtig vermutet.
Das Signal /IRE wirkt u.a. mit /mreq auf das Signal /WAIT (Nr. 79 in robbis Plan). Damit wird die CPU kurz gebremst, bis sie wieder im Zeitraster von m0, /pm2 und /pm3 sitzt.

Grüße
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
06.04.2024, 20:56 Uhr
Bert

Zitat:

jute-tom schrieb
Ich plane, im Rahmen meines Tang-Nano-9k-Projektes ja auch den 6k-Ju+Te nachzubauen. Ich gehe davon aus, dasss es dabei sinnvoller ist, den Videoprozessors statt mit einem zweiten UB88x0 durch klassische FPGA-Hardware nachzubauen.

Im FPGA steht Dir vermutlich Dual-Port-RAM zur Verfügung. Damit würde dieser ganze Multiplexerkram auf der JU+TE-Videoerweiterung wegfallen. Und das Timing für das Auslesen läßt sich so sicher auch einfacher anpassen, als das Programm für den 'Videoprozessor' umzuschreiben.
Andererseits, wenn schon den Hauptprozessor emuliert wird, brauchst Du ja nur noch eine Kopie davon für den Videoteil...

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
06.04.2024, 22:44 Uhr
HeikoS

Ein Jammer, dass das KC-Treffen ins Wasser gefallen ist. Da könnte mal mal richtig die 8-Bit-Köppe rauchen lassen und mit Bier wieder löschen ... ;-)

@P.S.:

Zitat:

P.S. schrieb
... konnte Dank des sog. "Page-Modus" moderner dRAMs mit entsprechender RAS/CAS-Taktung innerhalb sehr kurzer Zeit (wenige 100ns) jeweils ein BWS- und ein CPU-Zugriff nacheinander realisiert werden. Störungen beim Bildaufbau sind somit ausgeschlossen.

Der Page-Mode ist aus meiner Sicht nicht die Lösung, die asynchronen CPU-Zugriffe in den Griff zu bekommen. Damit konnte man nur viel schneller z.B. die Pixel UND die Farbinformation innerhalb eines Zeitfensters (z.B. 8 Bildpunkte) holen, da diese Infos ja parallel im Ausgangssignal vorhanden sein müssen. Die CPU kann asynchron immer "dazwischenfunken", weil der Programmablauf ja niemals vorher bekannt ist. Es muss also zusätzlich noch eine Synchronisation erfolgen. Da die Bildinformation damals meist nicht gepuffert wurde in Shaddow-RAMs etc., hatte die IRM-Steuerung immer Vorrang und die CPU musste ein wenig ausgebremst werden. Dazu gibt es beim Z80 offiziell 2 Methoden:

- WAIT
- BUSRQ/BUSAK

Beim Spectrum gibt es Messungen dazu und erstaunlicherweise sind die Verluste bei der Rechenzeit sehr gering während der IRM-Zugriffe. Also eine sehr gelungene Entwicklung damals 1981 ! bei Sinclair, der geniale Mann dahinter war Richard Altwasser. Er wählte eine dritte Methode:

- Takt-Unterbrechung

So wie Du geschrieben hast, hat mich dieses Thema auch schon sehr früh beschäftigt, da der KC85/3, aber auch fast alle Eigenbauten und auch die einfachen BWS-Karten in den Bürocomputern (5120 ... etc.) dieses Geflacker hatten ... die NSW-Entwickler waren eben auch nicht schlecht ... ! ;-)

@Bert:
Also wird es im KC85/4 mit /WAIT gemacht, danke für die Info ! Machen andere Rechner auch, z.B. auch Speccy-Clones. Unfassbar, wie viele es z.B. nur bei den 'Freunden' gab. Oh, da fällt mir ein, bei mir liegt immer noch die rote Leiterplatte des Leningrad II von Sven ... sorry Sven, habs immer noch nicht begonnen.

@Thomas:
Das ist ein cooles Projekt ! Der JuTe 6K gefällt mir sehr, weil er so ein Exot ist. Als ich das erste Mal das Konzept mit dem zweiten EMR als "Video-Prozessor" gesehen hatte, dachte ich, der übernimmt bestimmt noch viel mehr Aufgaben. Aber leider nur die Bilderzeugung und leider auch nicht synchonisiert mit der Host-CPU - also wieder Geflacker - ich war enttäuscht. Aber die Liebe ist ungebrochen ... !

Meine Idee war, die bestehende Hardware weitgehend so zu lassen und zu schauen, ob man die Host- und Video-CPU nicht dazu bringen kann, sich besser "abzusprechen".

Dein Ansatz mit FPGA-Hardware bietet ja ganz andere Möglichkeiten. Ich bin sehr gespannt darauf. Die IRM-Adressierung ist aber auch beim 6K sehr merkwürdig. Jede 3. Zeile ist um 8 Bytes länger und die werden nicht benutzt.

Ich habe daher in der FCSL extra eine eigene Lookup-Tabelle generiert, um mit ein paar sehr schnellen Befehlen die Umrechung von X/Y-Koodinaten in IRM-Adressen machen zu können, die noch etwas schneller ist, als im ES4.0. Im FPGA müsste der IRM ja auch so abgebildet werden, damit alles kompatibel ist. Aber das Auslesen kann man ja anders machen, Dual-Port-RAM hatte ja Bert schon erwähnt.

Viele Grüße, Heiko

Dieser Beitrag wurde am 06.04.2024 um 23:13 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
07.04.2024, 09:51 Uhr
P.S.

@HeikoS <006>
Wenn die BWS-Steuerung (Ablaufsteuerung o. GDC) und die CPU mit getrennten Taktquellen betrieben werden, hast Du natürlich Recht. Das sollte man aber vermeiden und immer einen systemweiten Takt verwenden, der ggf. je nach Notwendigkeit auch noch runtergeteilt werden kann. Bei der Festlegung der Grundtakt-Frequenz müssen - wenn notwendig - auch die Voraussetzungen bei den Systemschaltkreisen berücksichtigt werden, insbesondere z.B. beim CTC für die Baud-gerechte Unterstützung serieller Schnittstellen.

Bzgl. Page-Mode: - Hast Du Dir mal das Taktschema von der GDC-StE -> http://www.ps-blnkd.de/EXPR/EXPR_GDC_Takt.zip angeschaut. Dort habe ich mir versucht Klarheit darüber zu verschaffen, wie dieser komplizierte Ablauf funktionieren soll.

Übrigens - einen Dual-Port-RAM habe ich für den KC85/3 in meinem SEW auch realisiert -> http://www.ps-blnkd.de/KC%2085/8kDPRAM.pdf
Es war ein sehr hilfreiches Werkzeug ...

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
07.04.2024, 23:41 Uhr
HeikoS

Hallo Peter,

interessante Projekte und Geschichten, die du auf deiner Seite hast. Die Erinnerungen an meine WF-Zeit in Schöneweide und Wuhlheide werden wach … war eine schöne Zeit. Ich war übrigens vor kurzem mal mit ein paar Leuten aus den alten Zeiten im Industrie-Salon. Eine sehr schöne Sammlung – habe den UZG und das DM 2020 wiederentdeckt … herrlich !

Ich habe mal in den Seiten deines Universal-Experimental-Rechners gestöbert. Der Entwicklungsbericht für die GDC Baugruppe und die Timing-Sheets sind ja noch „Beta“ … steht ja auch so drin. Da gibt es eine kurze Passage zum Page-Mode (S.15), aber im Zusammenhang mit dem Wide-Display-Mode. Der Page-Mode wird dafür genutzt, um schnell auf benachbarte, ungerade DRAM-Adressen zuzugreifen. Und genau dafür ist er auch super geeignet.

Der damals verwendet Page-Mode in den DRAMs konnte bei gleicher RAS-Adresse mehrere CAS-Adressen hintereinander verarbeiten. Damit konnte man schneller auf bestimmte Bereiche des DRAMs zugreifen. Limitiert natürlich durch die identischen RAS-Adressen.

Damit wird auch klar, warum der Page-Mode keine Lösung für konkurrierenden Zugriffe von CPU und BWS-Steuerung sein kann. Die CPU-Adressen sind vom Programm-Ablauf abhängig und können keine kontinuierliche, gemeinsame RAS-Adresse mit der BWS-Steuerung haben.

Ich würde also widersprechen. Auch bei gemeimsamer Takt-Basis geht das meines Wissens nach nicht. Man muss hier klar alle möglichen Fälle von konkurrierenden Zugriffszyklen analysieren und dann der BWS-Steuerung den Vorrang einräumen. Ich bin aber kein GDC-Experte – dort kommen u.U. ganz andere Verfahren zum Einsatz (Line-Buffer, Shaddow-RAMs, extrem schnelle Speicher …).

Beim ZX-Spectrum (bestimmt auch bei den KC’s) wird der Page-Mode verwendet, um die Pixel- und die Farbinformation schnell hintereinander aus dem DRAM zu lesen, da diese immer in einer festen Relation zueinander stehen und eine gemeinsame RAS-Adresse bilden. Zusätzlich müssen aber die BWS-Zugriffe der CPU mit der BWS-Steuerung synchronisiert werden, wenn man keine Störungen im Bild haben will, da sonst die Schieberegister für die Videosignalerzeugung beim CPU-Zugriff mit falschen Daten geladen werden.

Hier als Bsp. das Timing vom Original-Speccy, mit 3 unterschiedlichen Situationen eines Lesezugriffs der CPU auf den Video-RAM und das Handling durch CPU-Takt-"Verlängerung".

Viele Grüße, Heiko

man könnte sich ja mal im Salon treffen ...

Dieser Beitrag wurde am 08.04.2024 um 07:40 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
08.04.2024, 08:31 Uhr
P.S.

@HeikoS <008>
Ich bin am Mittwoch, 10.04.2024 wieder im Industriesalon, so gegen 15 Uhr. Will mich mit Frank treffen, der an diesem Tag wieder das Repaircafe betreibt ...

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber-, Marken- und Persönlichkeitsrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
08.04.2024, 10:52 Uhr
HeikoS

Ich melde mich mal per PN.

Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
08.04.2024, 23:34 Uhr
HeikoS

Da hier der GDC U82720 (µPD 7220) erwähnt wurde, hat mich dann doch mal interessiert, ob der GDC das Problem der Bildstörungen gelöst hatte. Ich hatte leider nie so einen Chip, habe also auch keine Erfahrung damit. Hier gab es ja sogar schon einen Nachbau der VIS3 und auch neue Treiber dafür, das ist wirklich toll !

Im Original-Dokument von NEC steht, dass man beim 7220 zwei Möglichkeiten hat:

- permanenter Zugriff (schnell) auf den IRM(BWS) -> Störungen im Display
- Zugriff während der H/V-Austastlücken (langsam) -> keine Störungen im Display

Als Lösung wird auch hier Dual-Port-RAM UND ein zweiter GDC vorgeschlagen.

Eine Frage an die GDC und VIS3-Experten: Hat die VIS3 wirklich auch diese Störungen, wenn nicht in der Auslastlücke gearbeitet wird ? In der Hardwarebeschreibung habe ich noch den DMA-Mode gefunden.

Grüße, Heiko

Dieser Beitrag wurde am 09.04.2024 um 07:11 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
09.04.2024, 06:14 Uhr
ralle

Bei der Suche nach einem DSAVE ,also aus dem CAOS Startbare BASIC-Programme, bin ich in der FA über einem Artikel, zumindest für den AC1 , gestoßen. Darin wird beschrieben, wie man einen flackerfreien Bildschirm hin bekommt. Aber fragt mich bitte nicht, welches Jahr und Ausgabe das ist.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
09.04.2024, 07:15 Uhr
HeikoS

Meinst Du einen "normalen" AC1 oder einen AC1 mit GDC?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
09.04.2024, 07:30 Uhr
HeikoS

In der hervorragenden Beschreibung des CP/M Treibers von Heiko Poppe steht es genau so. Ich dachte immer, der GDC hat eine andere Lösung dafür schon integriert. Das ist ja die klassische Lösung, die damals alle gemacht hatten, denen das Geflacker auf die Nerven ging, aber mit hohen Verlusten bei der Geschwindigkeit der Bildschirmausgaben bezahlt wurde.

Man lernt nie aus:

Quellcode:


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Funktion 04: Schreibmodus
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Bei Schreibmodus = 0 wird der Zugriff des GDC auf den Bildspeicher nur in den Austastluecken erlaubt. Damit werden Bildstoerungen beim Schreib- oder Lesezugriff verhindert. Bei Schreibmodus = 1 ist der Zugriff immer erlaubt, das fuehrt zu sichtbaren Bildstoerungen. Hinweis: Bei den Zeichenfunktionen ist der Geschwindigkeitsvorteil sehr gering. Bei Nutzung der DMA-Funktion ist der Unterschied deutlich sichtbar.

Dieser Beitrag wurde am 09.04.2024 um 09:35 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
09.04.2024, 08:58 Uhr
ralle

Den Normalen AC1.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
09.04.2024, 09:49 Uhr
HeikoS

Zitat:

ralle schrieb
Bei der Suche nach einem DSAVE ,also aus dem CAOS Startbare BASIC-Programme, bin ich in der FA über einem Artikel, zumindest für den AC1 , gestoßen. Darin wird beschrieben, wie man einen flackerfreien Bildschirm hin bekommt. Aber fragt mich bitte nicht, welches Jahr und Ausgabe das ist.

Ja, das hatte ich auch noch im "Hinterkopf", danke für das Auffrischen !
Das ist dann diese Lösung:

http://www.ac1-info.de/galerie/weidlich_rolf/weidlich.htm#oktober_2018_entstoerung

Und da wird tatsächlich mit /WAIT gearbeitet, ist ähnlich der KC85/4-Lösung, denke ich. Habe das aber noch nicht genau angeschaut, aber ich denke, das ist wesentlich besser gelöst als nur in der Austastlücke zu arbeiten.

NACHTRAG:

Hier ist alles beschrieben: http://www.ac1-info.de/literatur/fa_88_10.htm

So wie es Bert auch für den KC85/4 geschrieben hat. Sehr gute Lösung !

Grüße,
Heiko

Dieser Beitrag wurde am 09.04.2024 um 16:14 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
09.04.2024, 18:24 Uhr
ralle

Beim KC85/2 und /3 wurde es per Software gelöst. Pharao nutzt ein Timingeffekt, um weitestgehend störungsfrei die Animation durch das Labyrinth darzustellen. Das ist allerdings das einzige bekannte.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
09.04.2024, 23:17 Uhr
HeikoS

Ja, bei "Neuauflage M033/M045/M046/M047 " hattest du das ja konkret benannt:

Zitat:

ralle schrieb
Bei Pharao wird die Austastlücke genutzt, zudem der /2 und /3 einen anderen Bildaufbau hat. Das hat man bei der Portierung leider nicht bedacht. Deshalb ist das auf dem /4 unspielbar.
--
Gruß Ralle

Das ist ja der Klassiker, um diese Störungen zu vermeiden. Die Austastlücke muss dann von der Software abgefragt werden, das Signal liegt meist an einem IO-Port an. Der Rechner wird aber ganz schön ausgebremst, wenn viele Zugriffe auf den BWS erfolgen, gerade bei Spielen und grafischen Anwendungen.

Angefangen hat dieser Thread ja genau an diesem Punkt. Ich würde gerne am JuTe 6K ein Verfahren, ähnlich dem AC1 oder KC85/4 ausprobieren. Der Host-Prozessor müsste vom Video-Prozessor etwas "ausgebremst" werden. Da der Z8 kein WAIT besitzt, könnte man mal über die Methode vom ZX-Spectrum nachdenken ... Host-CPU-Takt unterbrechen/verlängern <008>. Aber das ist erstmal nur ein Gedanke. Ob das vom Timing her geht und wie viel Aufwand das bedeutet, müsste man erst noch prüfen. Aber - s. beim AC1 - mit ein paar klugen Ideen lässt sich manchmal viel erreichen.

Grüße, Heiko

Dieser Beitrag wurde am 09.04.2024 um 23:32 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]